Re: [dev] Shell style guide

From: Evan Gates <evan.gates_AT_gmail.com>
Date: Tue, 6 Sep 2016 12:27:49 -0700

On Tue, Sep 6, 2016 at 12:10 PM, hiro <23hiro_AT_gmail.com> wrote:
> to me it sounds overly cautious, like a shell equivalent of: never use
> goto, always use braces, etc.. i don't like writing like this.

Most of it is avoiding things that are broken by design, like code
that can't handle filenames that being with - or include spaces or
glob characters. The vast majority of shell bugs stem from not quoting
expansions.

> using bash features should not be allowed *at all*, so neither
> #!/path/to/bash or #!/usr/bin/env bash is ok.
> #!/usr/bin/env is always wrong, /bin/sh is the only right one.

Sadly there is a lot of software these days that requires bash.
Hopefully we can avoid most of it, but I'm sure it'll pop up now and
then. I'd say anything that can't be done well/safely in sh should be
done in rc, but bash is ubiquitous. (The biggest problem with sh is
that it does not support arrays)

> i use backticks, they might be unfortunate, but they work fine as they
> are part of the language.

Sure they can work, but once you need to nest they are a fragile PITA.
I think "$()" is more readable and easier to use.

>> Echo and printf: Do not use echo if your input includes a variable or
>> backslash. There is no safe way to do so. Use printf and %s instead.
>
> Please elaborate, i didn't know about such an issue.

Using echo to print anything other than plain text is completely non
portable. POSIX says it should have no options, and just print a
string, unless it's an XSI conformant system in which case it needs to
interpret backslash escapes. From the POSIX description:

A string to be written to standard output. If the first operand is -n,
or if any of the operands contain a <backslash> character, the results
are implementation-defined.

When printing variables it's better to use printf %s\\n "$var" than to
do echo "$var" to cover cases where var is -n or -e or contains \a
etc.
Received on Tue Sep 06 2016 - 21:27:49 CEST

This archive was generated by hypermail 2.3.0 : Tue Sep 06 2016 - 21:36:11 CEST