Quoth Evan Gates:
> On Thu, Sep 8, 2016 at 5:44 AM, Nick <suckless-...@njw.me.uk> wrote:
> > I think this is something one learns with time. There are several
> > good reasons not to quote substitutions, such as passing multiple
> > arguments to another program (e.g. cmd $@), or a for or case
> > statement. But yes, quoting is essential most of the time.  Shell
> > escaping sucks, though, obviously. Another reason to keep bourne
> > shell very simple.
> 
> No. $@ is another example of something that _must_ be quoted every
> time. When inside quotes the shell expands it correctly to a word for
> each parameter. Without quotes the shell will do extra word splitting
> and globbing. For example, try this:
> 
> nargs() { echo "$#"; }
> set -- foo 'bar baz'
> echo "$#"
> nargs "$@"
> nargs $@

Ah, my bad, I did not know that, thanks. I thought that passing "$@" 
would just pass the contents of $@ as one string. And there I was 
considering myself well-versed on the ways of shell.

> When in a case statement should you not quote? I can't think of any examples.

Me neither. Ignore me :p

> I'm opposed to this. If you want convert, write convert. If you want
> gm convert, write gm convert. If you want to be able to change it
> everywhere in your script at once, put it in a function. Functions
> exist for exactly this reason. (That was strongly worded. If you write
> code that won't break, that's fine, but putting commands in variables
> obfuscates the code.)

How does it obfuscate the code to have "$convert a.png a.tif" versus 
"convert a.png a.tif" (where convert has been (re)defined as a 
function earlier in the script)? The former makes clear that you're 
just using the command in the convert variable, the latter does not.

> > I disagree. GNU ls may be, but it isn't supposed to be that way.
> > Something like `ls -tr | tail -n 1` seems perfectly reasonable to
> > me, for example. Sure you could use find, but for some cases ls is
> > simpler.
> 
> Simpler maybe, but incorrect. Filenames can contain newlines
> (filenames can contain everything but a / and a nul byte).

I am against writing scripts that can deal with filenames with 
newlines. Fuck such filenames. If you have to deal with them, shell 
scripting is a terrible technology to use.

Reply via email to