Re: [dev] Shell style guide

From: Nick <suckless-dev_AT_njw.me.uk>
Date: Thu, 8 Sep 2016 15:30:52 +0100

Quoth Evan Gates:
> On Thu, Sep 8, 2016 at 5:44 AM, Nick <suckless-dev_AT_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 $_AT_), 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. $_AT_ 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 "$_AT_"
> nargs $_AT_

Ah, my bad, I did not know that, thanks. I thought that passing "$_AT_"
would just pass the contents of $_AT_ 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.
Received on Thu Sep 08 2016 - 16:30:52 CEST