Re: [DNG] [OT] bash / quote weirdness
Simon said on Thu, 13 Jan 2022 18:38:56 + >Steve Litt wrote: > >> This is one reason why, in shellscripts, you >> need to quote almost all variables: So they act correctly with the >> space laden filenames that windows dwoobydogs just love to create. > >Not just Windows users. I regularly use spaces in file names. > >There’s an argument that computers should be tools, not slavemasters. >I’m sure you’ll remember going back a few decades how interacting with >computers meant that the human had to learn how to deal with the >computer’s way of doing things. The preceding is true to a great extent. But not a total extent. There's a tradeoff between user friendly and program simplicity. I don't think substituting underscores for spaces **in filenames** is a substantial inconvenience for the user. [snip] >Similarly with file names. Once upon a time the human had to adapt to >what the computer supported - such as fitting your entire file name >into 8 characters. But that kind of restriction isn't being discussed here. It's a strawman. > Now the computer (mostly) supports what is natural >for a human - and that includes using spaces in their writing. >After_all_it_does_seem_a_bit_un-natural_not_being_allowed_to_use_spaces_in_your_writing_-_it_would_make_a_hard_to_read_book_! We're not talking about books. Or text files. Or anything except filenames. Very_few_people_make_filenames_this_long, and if they do, with a little practice it's pretty easy to use underscore instead of space. As long as we're strawmanning, let's go all the way. Instead of issuing "file not found" when a filename isn't found, we can include an AI module in every program that decides what the user *really* meant when typing in the filename. It can analyze every filename on the computer, perhaps look at its contents, and then decide which the user really wanted, and open that one. Or, if the file is clicked from a file manager type interface, the AI can analyze all similarly named files in that directory and others, and issue an "Are you sure" with ranked choices of other possibilities. My point is that sure a computer should be more of a tool than a slavemaster, but it's a tradeoff, not an absolute. There's a spectrum. Programming around every conceivable filename increases software complexity. Let's not forget that simplicity and small attack surface are assets. One more thing: One person's "user friendly" is another person's "user hostile". The "we do it all for you" interface aiding the person not willing to bend at all to the machine is the "we get in your way" interface for the person who wants to bend the machine to his/her workflow. SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] bash / quote weirdness
Olaf Meeuwissen said on Fri, 14 Jan 2022 18:40:40 +0900 >Hi, > >Steve Litt writes: > >> [...] Here at Troubleshooters.Com, spaces and all punctuation except >> underscore and hyphen are forbidden, but files coming in from the >> outside have horrible filenames. > >Pretty sure you allow periods too ;-P Yes, I allow periods too. Forgot about that. But I try to use the periods only to separate the filetype and try to have only one period in the fileNAME. SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] bash / quote weirdness
Hi, Steve Litt writes: > [...] Here at Troubleshooters.Com, spaces and all punctuation except > underscore and hyphen are forbidden, but files coming in from the > outside have horrible filenames. Pretty sure you allow periods too ;-P -- Olaf MeeuwissenFSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] bash / quote weirdness
On Thu 13/Jan/2022 19:38:56 +0100 Simon wrote: Similarly with file names. Once upon a time the human had to adapt to what the computer supported - such as fitting your entire file name into 8 characters. Now the computer (mostly) supports what is natural for a human - and that includes using spaces in their writing. After_all_it_does_seem_a_bit_un-natural_not_being_allowed_to_use_spaces_in_your_writing_-_it_would_make_a_hard_to_read_book_! Indeed, early writings didn't use spaces, not even underscores, to separate words. And they had no 'puters at the time. Spaces in filenames may look friendlier than underscores, but they undergo a few annoying characteristics due to the fact that they cannot be seen. You cannot distinguish them from tabs, or do you have a convention to not use tabs in file names? And in that case may I ask why? Oh, tabs do something else in a "save as..." form? Well, spaces do something else when you use them on the command line. They require quoting, which is annoying. When used in URLs spaces become %20, which is not more readable than _. For some reason, nobody use spaces in the local part of email addresses, although the syntax allows it. People do so in order to be easier. Please don't use spaces in the names of files that you share. Best Ale -- ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] bash / quote weirdness
On Thu, Jan 13, 2022 at 06:38:56PM +, Simon wrote: > Steve Litt wrote: > > > This is one reason why, in shellscripts, you > > need to quote almost all variables: So they act correctly with the > > space laden filenames that windows dwoobydogs just love to create. > > Not just Windows users. I regularly use spaces in file names. > > There’s an argument that computers should be tools, not slavemasters. > I’m sure you’ll remember going back a few decades how interacting with > computers meant that the human had to learn how to deal with the computer’s > way of doing things. So, for example, typically when writing a document you > had an edit mode from which you couldn’t print, and a print mode (menu) from > which you couldn’t edit - you could not simply write you document and when > ready just tell the computer to print it. > > I recall a lot of resistance when Apple brought out the Mac and suddenly > programmers had to learn how to write programs that did what the user wanted > - when the user wanted. Sounds good. But for the first two years the Mac was out, programmers couldn't use it to write programs. To program it you had to use a much moe expensive machine, and Apple Lisa. Not what I, a potential user, wanter. After two years, somewone marketed a Pascal interpreter -- not even a compiler. -- hendrik >So, for example, open an editor, write your document, and whenever you want - >hit Cmd-P (or choose Print from the File menu) and it gets printed, right >there from inside your “edit mode”. > And now most people stuff like that for granted. rings have shifted from the > user doing the work to make the computer side easy to the user expecting the > computer side to do the work - after all, isn’t the purpose of computer to do > “stuff” for us ? > > Similarly with file names. Once upon a time the human had to adapt to what > the computer supported - such as fitting your entire file name into 8 > characters. Now the computer (mostly) supports what is natural for a human - > and that includes using spaces in their writing. > After_all_it_does_seem_a_bit_un-natural_not_being_allowed_to_use_spaces_in_your_writing_-_it_would_make_a_hard_to_read_book_! > > > > Another OT anecdote. This talk of spaces and quoting reminds me of an issue I > had to deal with a couple of work hats ago. I had some users who would > struggle sometimes to log into their terminals on the SCO OpenServer system. > When I watched them carefully, I’d see them mistyping either their username > or password, so for example assume their username is “username”, they might > mistype it thus : “usermname” rather than “usermname”. > Because it looked OK on the screen, it was hard to persuade them that what > the system saw them type was “usermname” and not the “username” > they could clearly see on the screen. > > > Simon > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] bash / quote weirdness
Steve Litt wrote: > This is one reason why, in shellscripts, you > need to quote almost all variables: So they act correctly with the > space laden filenames that windows dwoobydogs just love to create. Not just Windows users. I regularly use spaces in file names. There’s an argument that computers should be tools, not slavemasters. I’m sure you’ll remember going back a few decades how interacting with computers meant that the human had to learn how to deal with the computer’s way of doing things. So, for example, typically when writing a document you had an edit mode from which you couldn’t print, and a print mode (menu) from which you couldn’t edit - you could not simply write you document and when ready just tell the computer to print it. I recall a lot of resistance when Apple brought out the Mac and suddenly programmers had to learn how to write programs that did what the user wanted - when the user wanted. So, for example, open an editor, write your document, and whenever you want - hit Cmd-P (or choose Print from the File menu) and it gets printed, right there from inside your “edit mode”. And now most people stuff like that for granted. rings have shifted from the user doing the work to make the computer side easy to the user expecting the computer side to do the work - after all, isn’t the purpose of computer to do “stuff” for us ? Similarly with file names. Once upon a time the human had to adapt to what the computer supported - such as fitting your entire file name into 8 characters. Now the computer (mostly) supports what is natural for a human - and that includes using spaces in their writing. After_all_it_does_seem_a_bit_un-natural_not_being_allowed_to_use_spaces_in_your_writing_-_it_would_make_a_hard_to_read_book_! Another OT anecdote. This talk of spaces and quoting reminds me of an issue I had to deal with a couple of work hats ago. I had some users who would struggle sometimes to log into their terminals on the SCO OpenServer system. When I watched them carefully, I’d see them mistyping either their username or password, so for example assume their username is “username”, they might mistype it thus : “usermname” rather than “usermname”. Because it looked OK on the screen, it was hard to persuade them that what the system saw them type was “usermname” and not the “username” they could clearly see on the screen. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] bash / quote weirdness
On 1/13/22 09:43, Antony Stone wrote: On Thursday 13 January 2022 at 15:07:22, Hendrik Boom wrote: On Wed, Jan 12, 2022 at 05:45:08PM -0500, Steve Litt wrote: [slitt@mydesk ~]$ cat -n /etc/fstab | cut -b 1-20 | head -n5 1 UUID=730eaf92 2 UUID=41abb5fd 3 UUID=96cfdfb3 4 UUID=6F66-BF7 5 tmpfs /tmp tm [slitt@mydesk ~]$ "cat -n" /etc/fstab | cut -b 1-20 | head -n5 bash: cat -n: command not found [slitt@mydesk ~]$ "cat -n /etc/fstab" | cut -b 1-20 | head -n5 bash: cat -n /etc/fstab: No such file or directory So if it has parameters it's a command, and if it diesn't it's just a file or directory? It looks a good deal more complicated than that... $ "cat /etc/fstab" bash: cat /etc/fstab: No such file or directory $ "cat fstab" bash: cat fstab: command not found I have no idea what's really going on here. Antony. Really very simple. Bash interprets the string in total. It does not parse it for content prior to attempting to execute it. To do that, you need to change the context: eval "cat /etc/fstab" This behavior is well documented on the Bash man page and in all books on shell programming. It is also true for other P-code or interpreted languages such as Perl. -- William (Bill) Moss billm...@acm.org NY (USA) Those who will not reason, are bigots, those who cannot, are fools, and those who dare not, are slaves. Lord Byron Justice will not be served until those who are unaffected are as outraged as those who are. Benjamin Franklin When the people fear the government there is tyranny, when the government fears the people there is liberty. John Basil Barnhill ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] bash / quote weirdness
Hi everyone,
to better understand how the shell interprets quotes, you should compile
and use the following small C program to test some expressions :
$ cat args.c
#include
#include
int main(int argc, char *argv[])
{
int _i;
printf("ARGC = %d\n", argc);
for (_i = 1; _i < argc; _i++) {
printf("ARGV[%3d : length = %3d] = [%s]\n",
_i, strlen(argv[_i]), argv[_i]);
}
return 0;
}
Now, test your expressions :
$ xcmd="unrar x"
$ args xcmd
ARGC = 2
ARGV[ 1 : length = 4] = [xcmd]
$ args $xcmd
ARGC = 3
ARGV[ 1 : length = 5] = [unrar]
ARGV[ 2 : length = 1] = [x]
$ args "$xcmd"
ARGC = 2
ARGV[ 1 : length = 7] = [unrar x]
$ args '$xcmd'
ARGC = 2
ARGV[ 1 : length = 5] = [$xcmd]
$ args "cat /etc/fstab"
ARGC = 2
ARGV[ 1 : length = 14] = [cat /etc/fstab]
Regards,
Martial
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] bash / quote weirdness
On Thursday 13 January 2022 at 18:19:23, Benjamin Riefenstahl wrote: > Steve Litt writes: > > [slitt@mydesk ~]$ "cat -n" /etc/fstab | cut -b 1-20 | head -n5 > > bash: cat -n: command not found > > [slitt@mydesk ~]$ "cat -n /etc/fstab" | cut -b 1-20 | head -n5 > > bash: cat -n /etc/fstab: No such file or directory > > When there is a "/" in the command name, that is a file that has to exist by > that exact name (the file name can be relative, though). > > When there is no "/", then and only then the command is searched along > $PATH, and if it is not found there, the error message is different from the > other case. > > At least that is my explanation. This makes excellent sense and is a good explanation, I believe. Thanks, Antony. -- Anyone that's normal doesn't really achieve much. - Mark Blair, Australian rocket engineer Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] bash / quote weirdness
No problem. Happy that you found it useful :D On Thu, 2022-01-13 at 10:52 -0500, Steve Litt wrote: > Thank you, thank you, THANK YOU!!! > > I've needed this for the last 23 years. Thank you! > > SteveT ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] bash / quote weirdness
Anno domini 2022 Thu, 13 Jan 15:43:29 +0100
Antony Stone scripsit:
> On Thursday 13 January 2022 at 15:07:22, Hendrik Boom wrote:
>
> > On Wed, Jan 12, 2022 at 05:45:08PM -0500, Steve Litt wrote:
>
> > > [slitt@mydesk ~]$ cat -n /etc/fstab | cut -b 1-20 | head -n5
> > >
> > > 1UUID=730eaf92
> > > 2UUID=41abb5fd
> > > 3UUID=96cfdfb3
> > > 4UUID=6F66-BF7
> > > 5tmpfs /tmp tm
> > >
> > > [slitt@mydesk ~]$ "cat -n" /etc/fstab | cut -b 1-20 | head -n5
> > > bash: cat -n: command not found
> > >
> > > [slitt@mydesk ~]$ "cat -n /etc/fstab" | cut -b 1-20 | head -n5
> > > bash: cat -n /etc/fstab: No such file or directory
> >
> > So if it has parameters it's a command, and if it diesn't it's just
> > a file or directory?
>
> It looks a good deal more complicated than that...
>
> $ "cat /etc/fstab"
> bash: cat /etc/fstab: No such file or directory
>
> $ "cat fstab"
> bash: cat fstab: command not found
>
> I have no idea what's really going on here.
Your example misses a minor detail. "" and '' build strings with/without
variable substitution (e.g. A="cat /etc/fstab"). When passed as a not-quoted
variable (e.g. $A) to the current shell the whole string is broken up into
arguments at whitespaces (e.g. $A -> "cat" "/etc/fstab"), the first argument is
the command that gets passed all remaining arguments including pipe symbols
('|'). A quoted variable is passed as one argument ("$A" -> "car /etc/fstab") -
if it's the only argument then that programm/command/function is evaluated and
is most likely to fail. Note that the pipe symbol ("|") as part of a string is
passed as an argument or part of an argument to argument 0 (command) and does
not build a pipe.
Nik
>
>
> Antony.
>
--
Please do not email me anything that you are not comfortable also sharing with
the NSA, CIA ...
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] bash / quote weirdness
Antony Stone said on Thu, 13 Jan 2022 15:43:29 +0100 >$ "cat fstab" >bash: cat fstab: command not found > >I have no idea what's really going on here. > > >Antony. Hi Anthony, Different programs handle commands with arguments different ways. sed -e handles the string that follows, which must be in quotes, as several different words. The C system() function handles its one string argument the same way, busting it into words delineated by spaces or beginning or end of line. On the other hand, the C execve() function is fed an array of strings, and doesn't do any splitting itself. Likewise, my /bin/sh, which I believe is a symlink for dash, takes a series of whitespace separated strings. If you quote something with a one or more spaces inside, dash considers the entire quoted entity to be exactly one string. This is one reason why, in shellscripts, you need to quote almost all variables: So they act correctly with the space laden filenames that windows dwoobydogs just love to create. Here at Troubleshooters.Com, spaces and all punctuation except underscore and hyphen are forbidden, but files coming in from the outside have horrible filenames. I'm pretty sure that, pertaining to quotes and whitespace, bash acts like my dash. I quit using bash in shellscripts after that horrific SHELLSHOCK security flaw (CVE-2014-6271) in 2014 and never came back. Dash has a smaller attack surface. This isn't to say I don't use bash. It's a spectacular interactive shell. But I never use it for shellscripts. In 2014 I had to rewrite over 100 shellscripts to use #!/bin/sh instead of #!/bin/bash. So when you issue a command from a shellscript, that command must be free from quotes except in places where the quoted material is intentionally one string. SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] bash / quote weirdness
Gabe Stanton via Dng said on Thu, 13 Jan 2022 07:03:57 -0700 >There's an html version and a pdf version of the abs guide available >here > >https://tldp.org/LDP/abs/html/ > >or here > >https://tldp.org/LDP/abs/abs-guide.pdf Thank you, thank you, THANK YOU!!! I've needed this for the last 23 years. Thank you! SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] bash / quote weirdness
On Thursday 13 January 2022 at 15:07:22, Hendrik Boom wrote: > On Wed, Jan 12, 2022 at 05:45:08PM -0500, Steve Litt wrote: > > [slitt@mydesk ~]$ cat -n /etc/fstab | cut -b 1-20 | head -n5 > > > > 1 UUID=730eaf92 > > 2 UUID=41abb5fd > > 3 UUID=96cfdfb3 > > 4 UUID=6F66-BF7 > > 5 tmpfs /tmp tm > > > > [slitt@mydesk ~]$ "cat -n" /etc/fstab | cut -b 1-20 | head -n5 > > bash: cat -n: command not found > > > > [slitt@mydesk ~]$ "cat -n /etc/fstab" | cut -b 1-20 | head -n5 > > bash: cat -n /etc/fstab: No such file or directory > > So if it has parameters it's a command, and if it diesn't it's just > a file or directory? It looks a good deal more complicated than that... $ "cat /etc/fstab" bash: cat /etc/fstab: No such file or directory $ "cat fstab" bash: cat fstab: command not found I have no idea what's really going on here. Antony. -- "It would appear we have reached the limits of what it is possible to achieve with computer technology, although one should be careful with such statements; they tend to sound pretty silly in five years." - John von Neumann (1949) Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] bash / quote weirdness
On Wed, Jan 12, 2022 at 05:45:08PM -0500, Steve Litt wrote: > > On the other hand... > > === > [slitt@mydesk ~]$ cat -n /etc/fstab | cut -b 1-20 | head -n5 > 1UUID=730eaf92 > 2UUID=41abb5fd > 3UUID=96cfdfb3 > 4UUID=6F66-BF7 > 5tmpfs /tmp tm > [slitt@mydesk ~]$ "cat -n" /etc/fstab | cut -b 1-20 | head -n5 > bash: cat -n: command not found > [slitt@mydesk ~]$ "cat -n /etc/fstab" | cut -b 1-20 | head -n5 > bash: cat -n /etc/fstab: No such file or directory > [slitt@mydesk ~]$ So if it has parameters it's a command, and if it diesn't it's just a file or directory? -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] bash / quote weirdness
I don't have anything of my own to add except that single quotes result in the same behavior as double quotes in this case. I was curious about that after reading about the difference between single and double quotes in the Advanced Bash Scripting Guide or abs guide. I'm a novice obviously. I wanted to share the abs guide in case anyone reading isn't aware of it. I found it recently while working on a script myself (rename files and folders according to a standard, all lower case, limited special characters and no spaces in case anyone finds it interesting). There's an html version and a pdf version of the abs guide available here https://tldp.org/LDP/abs/html/ or here https://tldp.org/LDP/abs/abs-guide.pdf Gabe On Wed, 2022-01-12 at 00:08 +0100, Florian Zieboll via Dng wrote: > Dear list, > > this im my 'test.sh': > > #!/bin/bash > for f in "$@" ; do > xcmd="unrar x" > $xcmd "$f" > done > > Can please somebody explain, why, if I double-quote the "$xcmd" > variable in line 4, the script fails with > > ./test.sh: line 4: unrar x: command not found > > ??? > > Commands without parameters resp. whitespace (e.g. xcmd="unzip") work > fine when double-quoted; a web search (including the "GNU Bash > manual" > [1]) did not shed any light on this mystery... > > Thank you and libre Grüße, > Florian > > > > [1] > https://www.gnu.org/software/bash/manual/html_node/Double-Quotes.html > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] bash / quote weirdness
Alessandro Vesely via Dng said on Wed, 12 Jan 2022 10:39:07 +0100
>On Wed 12/Jan/2022 01:27:45 +0100 Florian Zieboll via Dng wrote:
>> On Tue, 11 Jan 2022 18:52:10 -0500
>> william moss wrote:
>>
>>> Bash is taking the string in the double quotes as a single command;
>>> this is well documented. If either the command or parameters have
>>> spaces, you will have to use eval. Check the bash man page for
>>> details.
>>>
>>> This will also usually work
>>> X=$( "command and such" )
>>> due to the execute block.
>>
>> I am replying to the list to share the valid (tested) alternative.
>> Thanks a lot!
>
>
>Bash still considers a quoted command as such, for example:
>
>ale@pcale:~/tmp$ X=$("echo foo")
>bash: echo foo: command not found
On the other hand...
===
[slitt@mydesk ~]$ cat -n /etc/fstab | cut -b 1-20 | head -n5
1 UUID=730eaf92
2 UUID=41abb5fd
3 UUID=96cfdfb3
4 UUID=6F66-BF7
5 tmpfs /tmp tm
[slitt@mydesk ~]$ "cat -n" /etc/fstab | cut -b 1-20 | head -n5
bash: cat -n: command not found
[slitt@mydesk ~]$ "cat -n /etc/fstab" | cut -b 1-20 | head -n5
bash: cat -n /etc/fstab: No such file or directory
[slitt@mydesk ~]$
===
SteveT
Steve Litt
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] bash / quote weirdness
On 1/12/22 04:39, Alessandro Vesely via Dng wrote:
On Wed 12/Jan/2022 01:27:45 +0100 Florian Zieboll via Dng wrote:
On Tue, 11 Jan 2022 18:52:10 -0500
william moss wrote:
Bash is taking the string in the double quotes as a single command;
this is well documented. If either the command or parameters have
spaces, you will have to use eval. Check the bash man page for
details.
This will also usually work
X=$( "command and such" )
due to the execute block.
I am replying to the list to share the valid (tested) alternative.
Thanks a lot!
Bash still considers a quoted command as such, for example:
ale@pcale:~/tmp$ X=$("echo foo")
bash: echo foo: command not found
Best
Ale
X=$( eval "echo foo" )
echo "$X"
foo
--
William (Bill) Moss
billm...@acm.org
NY (USA)
Those who will not reason, are bigots,
those who cannot, are fools,
and those who dare not, are slaves.
Lord Byron
Justice will not be served until those who are
unaffected are as outraged as those who are.
Benjamin Franklin
When the people fear the government there is
tyranny, when the government fears the people
there is liberty.
John Basil Barnhill
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] bash / quote weirdness
On Wed, 12 Jan 2022 10:39:07 +0100
Alessandro Vesely via Dng wrote:
> On Wed 12/Jan/2022 01:27:45 +0100 Florian Zieboll via Dng wrote:
> >
> > I am replying to the list to share the valid (tested) alternative.
> > Thanks a lot!
>
>
> Bash still considers a quoted command as such, for example:
>
> ale@pcale:~/tmp$ X=$("echo foo")
> bash: echo foo: command not found
Hallo Alessandro,
you're right. I can't reproduce my nightly "successful test" and assume,
that I had accidentally worked on a zip archive instead of a rar...
Thanks for clarification and libre Grüße,
Florian
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] bash / quote weirdness
On Wed 12/Jan/2022 01:27:45 +0100 Florian Zieboll via Dng wrote:
On Tue, 11 Jan 2022 18:52:10 -0500
william moss wrote:
Bash is taking the string in the double quotes as a single command;
this is well documented. If either the command or parameters have
spaces, you will have to use eval. Check the bash man page for
details.
This will also usually work
X=$( "command and such" )
due to the execute block.
I am replying to the list to share the valid (tested) alternative.
Thanks a lot!
Bash still considers a quoted command as such, for example:
ale@pcale:~/tmp$ X=$("echo foo")
bash: echo foo: command not found
Best
Ale
--
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] bash / quote weirdness
On Wed, 12 Jan 2022 01:10:11 +0100 Antony Stone wrote: > Double-quoting turns the string into a single token, and therefore > the parser sees the line as: > > token 1 = "unrar x" > token 2 = "$f" > > Without the double quoting, it's: > > token 1 = "unrar" > token 2 = "x" > token 3 = "$f" > > "unrar" is a command which can be executed (in this case with a > parameter of "x"), whereas "unrar x" is not a command. > > You can see much the same thing if you try: > > for f in one two three four > do > echo "$f" > done > > for f in "one two" "three four" > do > echo "$f" > done > > > Antony. Hallo Antony, thank you - and yes, of course, that makes perfectly sense... As I have a strict "no whitespace policy" for my filesystems, I just wouldn't ever have thought of a command to contain one - and am still somewhat dumbfounded ;-) Libre Grüße, Florian ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] bash / quote weirdness
On Tue, 11 Jan 2022 18:52:10 -0500 william moss wrote: > Bash is taking the string in the double quotes as a single command; > this is well documented. If either the command or parameters have > spaces, you will have to use eval. Check the bash man page for > details. > > This will also usually work > X=$( "command and such" ) > due to the execute block. Hallo William, I am replying to the list to share the valid (tested) alternative. Thanks a lot! Libre Grüße, Florian ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] bash / quote weirdness
On Tue, 11 Jan 2022 18:16:15 -0500 tempforever wrote: > I believe quoting $xcmd would instruct the shell to look for and > execute "unrar x" so unless you have an executable file named unrar\ > x within $PATH, it will fail. The same thing happens within a shell: > ~$ "unrar x" > bash: unrar x: command not found > ~$ Hallo tempforever, thank you for your quick and simple reply. Seems that I can go sleep now :-) The full script, an archive batch-extractor (zip and rar supported so far) with absolutely no rights reserved, is attached. libre Grüße, Florian extract2newdir.sh Description: application/shellscript ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] bash / quote weirdness
On Wednesday 12 January 2022 at 00:08:38, Florian Zieboll via Dng wrote: > #!/bin/bash > for f in "$@" ; do > xcmd="unrar x" > $xcmd "$f" > done > > Can please somebody explain, why, if I double-quote the "$xcmd" > variable in line 4, the script fails with > > ./test.sh: line 4: unrar x: command not found Double-quoting turns the string into a single token, and therefore the parser sees the line as: token 1 = "unrar x" token 2 = "$f" Without the double quoting, it's: token 1 = "unrar" token 2 = "x" token 3 = "$f" "unrar" is a command which can be executed (in this case with a parameter of "x"), whereas "unrar x" is not a command. You can see much the same thing if you try: for f in one two three four do echo "$f" done for f in "one two" "three four" do echo "$f" done Antony. -- The lottery is a tax for people who can't do maths. Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] bash / quote weirdness
Florian Zieboll via Dng wrote: > Dear list, > > this im my 'test.sh': > > #!/bin/bash > for f in "$@" ; do > xcmd="unrar x" > $xcmd "$f" > done > > Can please somebody explain, why, if I double-quote the "$xcmd" > variable in line 4, the script fails with > > ./test.sh: line 4: unrar x: command not found > > ??? > > Commands without parameters resp. whitespace (e.g. xcmd="unzip") work > fine when double-quoted; a web search (including the "GNU Bash manual" > [1]) did not shed any light on this mystery... > > Thank you and libre Grüße, > Florian > > > > [1] https://www.gnu.org/software/bash/manual/html_node/Double-Quotes.html > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng I believe quoting $xcmd would instruct the shell to look for and execute "unrar x" so unless you have an executable file named unrar\ x within $PATH, it will fail. The same thing happens within a shell: ~$ "unrar x" bash: unrar x: command not found ~$ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] [OT] bash / quote weirdness
Dear list, this im my 'test.sh': #!/bin/bash for f in "$@" ; do xcmd="unrar x" $xcmd "$f" done Can please somebody explain, why, if I double-quote the "$xcmd" variable in line 4, the script fails with ./test.sh: line 4: unrar x: command not found ??? Commands without parameters resp. whitespace (e.g. xcmd="unzip") work fine when double-quoted; a web search (including the "GNU Bash manual" [1]) did not shed any light on this mystery... Thank you and libre Grüße, Florian [1] https://www.gnu.org/software/bash/manual/html_node/Double-Quotes.html ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
