Welcome, Guest. Please login or register.

AuthorTopic: THOR's Shell Hacks  (Read 1576 times)

0 Members and 1 Guest are viewing this topic.

Offline patrik

Re: THORs Shell Hacks
« Reply #75 on: March 25, 2017, 09:16:12 PM »
Quote from: ChaosLord;783434
@Thor
The reason I ask is because I do all my compiling and testing from shell.  I test for memory leaks a lot.  Many years ago I found that all the fancy shells that I tested such as KingCON: keep randomly changing the amount of ram that they consume so I can't easily check for memory leaks in my programs.
I think its because of their scrollback buffer constantly expanding.

I like to do
Code: [Select]

avail flush
run myGiantComplicatedProgram blahblah blah moreblah
avail flush

to see if my memory usage is the same before & after.

But that did not work in KingCON: and whatever fancy shells I tested.


Atleast with KingCON this works fine if you just disable the "Review"/scrollback in the menu. Otherwise you will loose memory for every additional line.
 

Offline kolla

Re: THORs Shell Hacks
« Reply #76 on: December 04, 2017, 10:19:43 AM »
Digging up this old thread... :)

@ThoR

Instead of writing, let me just illustrate my question...

(and this doesn't even show all my desperate attempts at escaping)

I hope it is obvious what I try to accomplish? :)

My goal was to have the content of a file displayed as the body of RequestChoice.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline Thomas Richter

Re: THORs Shell Hacks
« Reply #77 on: December 04, 2017, 01:18:10 PM »
The problem is that you escape improperly and at the wrong place. So let's start...

Code: [Select]
set blarb foo*nbar
sets the variable "blarb". However, the * is not in quotes, so it is a literal. Nothing will change that any more. So if you now print the contents of the variable or use it

Code: [Select]
echo ${blarb}
then this will print an asterisk, simply because there was an asterisk in the variable in the beginning.

If you try this:
Code: [Select]
echo "${blarb}"
then the shell will notice "Oops, he's putting the variable into quotes, so I need to escape its contents". And so the shell does. It detects that there is an asterisk in the variable contents, so it needs to escape this asterisk, and replaces it by two asterisks before passing it to echo, which will run into "ReadItem()" and again, replaces the two asterisks back to one.

If you want a line feed in a variable, you need to put it there in first place:

Code: [Select]
set blarb "foo*nbar"

*Now* the asterisks is in quotes, and means "escape character". And you can use the variable as such:

Code: [Select]
echo ${blarb}

or as such

Code: [Select]
echo "${blarb}"

and the line feed will stay a line feed. (-:
 

Offline kolla

Re: THORs Shell Hacks
« Reply #78 on: December 04, 2017, 02:28:10 PM »
Hm, so how do I make a variable that can subsitute "foo foo*nbar bar" in the below example, so that the requester pops up with two lines in body, like it does in the below example? I really tried using all your suggestions, and except for the last one, where it only expands to "foo foo" (the first line before line feed), all I ever get is literally "foo foo*nbar bar" (without quotes) in the body :)  

Code: [Select]
C:requestchoice title "test title" body "foo foo*nbar bar" gadgets "OK" "Cancel"

And worse yet - how to get the content of a file there, with linefeeds represented by "*n", using backticking? :)

Something that works, but isn't quite what I picture a solution...
Code: [Select]
set blarb foo foo
set blurb bar bar
requestchoice "testing" "${blarb}*n${blurb}" "OK"

so... with one variable per line, it works. But that is very cumbersome :)
« Last Edit: December 04, 2017, 03:50:55 PM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline Thomas Richter

Re: THORs Shell Hacks
« Reply #79 on: December 04, 2017, 09:54:48 PM »
Frankly, I'm not sure whether that is a bug or a feature. The problem here is that a variable with a line feed in the middle is cut at the line feed whenever you try to insert it.

Now, at first sight, this looks like a bug, and it is part of the GetVar() interface of the dos.library, not the shell (directly), which truncates variable contents at line feeds - unless you ask for "binary variables".

Well, has this been done? One can only guess, but consider the following case:

1> echo "foo" >env:bar

This sets the environment variable $bar to "foo", right?

Wrong. It sets it to "foo*N", which is not equal to "foo".

So in this case, it *seems* sensible to cut the variable contents at the *N.

In other cases, it is not. With the current shell interface, it will get the variable "to what you would expect to be right", but in other cases, truncation of the variable contents at a line feed is not what you want.

I do not yet have a clear answer to this problem and need to think about it.
 

Offline kolla

Re: THORs Shell Hacks
« Reply #80 on: December 05, 2017, 02:00:32 AM »
Thanks for all the thoughts and work you put into the shell updates!

And woop - found the solution - quotes inside the file :)

A file with content (including quotes):
Code: [Select]
"foo foo*nbar bar"and
Code: [Select]
echo `file`
vs a file with content (no quotes):
Code: [Select]
foo*nbarand (with or without quotes, makes no difference it seems)
Code: [Select]
echo "`type file`"
The first does work, the latter doesn't.

So, success - now I know how to alter files to show up as multiple lines with RequestChoice (still center aligned... hm) :)



(I really do an effort to just use ASL and not ReqTools etc)
« Last Edit: December 05, 2017, 02:02:59 AM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline LoadWB

Re: THORs Shell Hacks
« Reply #81 on: December 05, 2017, 04:18:33 PM »
That's pretty neat.  Never used RequestChoice but I can see it being quite handy.
 

Offline Thomas Richter

Re: THORs Shell Hacks
« Reply #82 on: December 05, 2017, 08:32:19 PM »
Well, I thought about this issue. It is really a bit tricky, and there are more inconsistencies in the shell I want to get rid of.

First, we have some weirdo, namely variables with blanks in it. So if we have
Code: [Select]
set a="a b"
Then, naturally,
Code: [Select]
command $a
results in "command" receiving two arguments, and
Code: [Select]
command "$a"
receiving one argument "a b".

If we set, however,
Code: [Select]
set a="*"a b*""
then
Code: [Select]
command $a
results in one argument, namely "a b". However, the V45 shell does for
Code: [Select]
command "$a"
also the same thing by first removing the outer quotes, hence giving effectively the same result. I believe this is wrong. As it is quoted, the quotes within the variable should be escaped, and hence the value preserved:
Code: [Select]
command "$a"
should call "command", but not with argument "a b", but with argument "*"a b*"", i.e. the quotes within the variable should be preserved.

As far as line feeds in variables are concerned: These can be really nasty. So if we have
Code: [Select]
set a="a*Nb"
and would then, without further modifications, call
Code: [Select]
command $a b
then the line feed within $a would terminate the line, and the command would never see the second argument. This is clearly undesired.

So I believe the following rule makes sense: If a variable is expanded within double quotes, it is expanded as a "binary variable", and the line feed stays within the double quotes, and is there - as part of the substitution process - replaced by a *N, so it is forwarded to the command.

If a variable is expanded outside of double quotes, the old rules apply and the variable is expanded as "text variable" and its contents is terminated at the first line feed, or \0, whatever comes first (this is how dos handles it).

I hope this makes sense...

A word about backticks: It is since ever that a line feed within backticks is replaced by a blank. This is also the case under Linux, and I believe it makes most sense in case a "list" command is put into the backticks. So I guess I keep it this way, unless somebody has a smart idea how to improve it without breaking too much.

Last but not least, we have one outsider, and this is the "rx" command. Unfortunately, this is not fixable as "rx" with arguments in quotes executes the script literally, i.e.
Code: [Select]
rx "say hello"
prints "HELLO" on the screen, whereas
Code: [Select]
rx say hello
executes the rexx script "say" (if it exists) with the argument "hello".

This all becomes a bit pathetic in case you have a volume named "say hello", as then the shell puts quotes around the volume name. Or to keep it simple, a rexx script on the "Ram Disk:". One cannot, possibly, execute it from there:
Code: [Select]
"Ram Disk:test.rexx"
on the shell will not work whatsoever, since the double quotes are needed to escape the volume name, but it changes the meaning of what "rx" attemts to do. Namely here not to execute a script on "Ram", but to execute the Rexx command "Ram" (which does not exist), with the argument "Disk:test.rexx". Bummer!

Replace "Ram Disk:" by "RAM:" and things work, but I guess Bill hasn't thought this one to the very end.

I hope there were people out here who could follow. This is all touchy business.
 

Offline LoadWB

Re: THORs Shell Hacks
« Reply #83 on: December 06, 2017, 02:32:52 AM »
I'm following.  I've had to deal with a lot of quirks regarding spaces and quotes in arguments and filenames.  Does not make me happy.
 

Offline olsen

Re: THORs Shell Hacks
« Reply #84 on: December 06, 2017, 09:16:17 AM »
Quote from: Thomas Richter;833827
Well, I thought about this issue. It is really a bit tricky, and there are more inconsistencies in the shell I want to get rid of.

Last but not least, we have one outsider, and this is the "rx" command. Unfortunately, this is not fixable as "rx" with arguments in quotes executes the script literally, i.e.
Code: [Select]

rx "say hello"
prints "HELLO" on the screen, whereas
Code: [Select]

rx say hello
executes the rexx script "say" (if it exists) with the argument "hello".

This all becomes a bit pathetic in case you have a volume named "say hello", as then the shell puts quotes around the volume name. Or to keep it simple, a rexx script on the "Ram Disk:". One cannot, possibly, execute it from there:
Code: [Select]

"Ram Disk:test.rexx"
on the shell will not work whatsoever, since the double quotes are needed to escape the volume name, but it changes the meaning of what "rx" attemts to do. Namely here not to execute a script on "Ram", but to execute the Rexx command "Ram" (which does not exist), with the argument "Disk:test.rexx". Bummer!

Replace "Ram Disk:" by "RAM:" and things work, but I guess Bill hasn't thought this one to the very end.

I hope there were people out here who could follow. This is all touchy business.


The ARexx shell commands might be fixable. I rewrote all of them in 'C' for AmigaOS4. The rx command is weird, though, but at least the 'C' language version uses ReadArgs() and falls back onto parsing GetArgStr() in case the "command line parameters" are a single line ARexx program.
 

Offline kolla

Re: THORs Shell Hacks
« Reply #85 on: December 07, 2017, 01:28:34 AM »
Quote from: LoadWB;833817
That's pretty neat.  Never used RequestChoice but I can see it being quite handy.


Yes it, plenty of room for more functionality though :)

As I mention, it center aligns, no matter, with fixed width fonts you can sort of work around it using some "invisble" character to have all lines equally long, but with normal fonts that gets messed up too. Would help if it understood tabs, for example.

Which reminds me - the shell has no concept of tabs, no *T :)

Btw, what I'm doing with this, is making a simple script with requesters for picking an available wifi network, parsing output from wpa_cli commands on "remote" (built into Amiga case) raspberry pi, via rsh (Thanks again, Olsen!). I try to avoid too much third party dependencies in my scripts, so they are more likely to work on all my systems, including the ones low on resources.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline Oldsmobile_Mike

Re: THORs Shell Hacks
« Reply #86 on: December 07, 2017, 02:28:45 AM »
Quote from: kolla;833786




Just quoting this because those are some of the most amusing requester choices I've ever seen.  ;)

Also, what are you using to get the additional buttons at the top of your Shell window?  (Help, Settings)
Amiga 500: 2MB Chip|16MB Fast|30MHz 68030+68882|3.9|Indivision ECS|GVP A500HD+|Mechware card reader + 8GB CF|Cocolino|SCSI DVD-RAM
Amiga 2000: 2MB Chip|136MB Fast|50MHz 68060|3.9|Indivision ECS + GVP Spectrum|Mechware card reader + 8GB CF|AD516|X-Surf 100|RapidRoad|Cocolino|SCSI CD-RW
 Amiga videos and other misc. stuff at https://www.youtube.com/CompTechMike/videos
 

Offline kolla

Re: THORs Shell Hacks
« Reply #87 on: December 07, 2017, 05:04:30 AM »
That's just default ViNCEd config of OS3.9, I only set it to using ansi colours, which is why the background is black.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline Thomas Richter

Re: THORs Shell Hacks
« Reply #88 on: December 07, 2017, 07:07:33 AM »
Quote from: kolla;833866
Which reminds me - the shell has no concept of tabs, no *T :)
This is actually not a matter of the shell. While (parts of) the shell generate such funny sequences, it is the matter of ReadItem() of the dos.library (and -through that- ReadArgs() also in the dos.library) to interpret them. So the definition of additional "funny letters" is out of my hands (oh, wait, not exactly, but I do not want to touch dos this time).

Right now *T would just escape to T.

If you want to insert a TAB, well, on ViNCEd, type "ESC", then press TAB, and you get a TAB control sequence in the string. Or edit the shell skript with an editor of your choice. Tabs are "literals", they can be inserted directly into quotes and stay there.