Re: Announcement: bashcritic
- From: Stephane CHAZELAS <this.address@xxxxxxxxxx>
- Date: Mon, 15 Oct 2007 20:15:07 GMT
2007-10-12, 08:07(-00), Teo:
Hi,[...]
after using Perl::Critic for a while (see
http://search.cpan.org/~elliotjs/Perl-Critic-1.078/lib/Perl/Critic.pm)
I had to idea to begin something similar for shell scripts. For
example to check for non-portable constructs and so on.
An initial prototype (in alpha stage) is available at:
https://trac.id.ethz.ch/projects/bashcritic/wiki/WikiStart
I began to add some tests for portability but I would really like some
feedback and some suggestions on what to check (I will in any case
monitor the group looking for possible candidates)
Some comments:
description => '"declare keyword" is not portable use
"typeset keyword" to define' . ' local variables (or
variables with special attributes).',
typeset is as non-standard as declare. typeset is ksh, declare
is bash. The only other Bourne-lie shell that supports anything
similar is zsh that supports both (plus "local").
In POSIX, you use subshells to have local variables ((...) or
$(...)).
description => 'Avoid here-strings (a special form of
the here-document)' . ' in portable scripts.',
Here strings are very recent in bash. So, on most "stable"
systems, even bash won't recognise it. The feature was borrowed
from ksh93 that borrowed it from zsh that borrowed it from rc.
It's of little use in scripts.
description => q{Though POSIX allows it, many shells
don' want the assignment} . ' and the exporting in one
command.',
No, there's only one Bourne-like shell that doesn't support
export var=value and that's the Bourne shell itself. The Bourne
shell is a non-POSIX shell from the old ages. You may want to
add a Bourne compatibility checking mode to your tool, but then,
there'll be many more things to check.
On the other hand, it should be noted that export behaves
differently depending on the shell.
For instance, in some shells (namely bash and the AT&T
implementations of ksh)
a="A B"
export b=$a
doesn't export the varibles b and B. Instead, it exports b with
as value "A B", which makes them non-POSIX conformant. So, here
even more than anywhere else, it's important to quote variable
expansions.
description => q{POSIX does't define an arithmetic
compund command, many shells} . q{don't know it. Using
the pseudo-command : and the arithmetic expansion} . q{
$(( )) is a kind of workaround here.},
However, some shells don't support assignments as in:
: $(( a = 1 + 1 ))
so I wouldn't give that advice.
a=$((1 + 1)) is prefered. $((...)) is not Bourne.
description => q{The Bashish test keyword "[[" is
reserved by POSIX, } . q{but not defined. Use the old
fashioned way with the test command} . q{ ("test" or
"[").},
As far as I know, bash didn't invent anything [[ is a kshism
also recognized by bash and zsh (with variations).
description => q{The &>FILE >&FILE redirection syntax is
short for >FILE 2>&1} . q{ and is derived from the
C-Shell. It's very old and not part of POSIX.},
No, csh's is >&, also found in zsh. It's not as old as most
features of bash that come from the Bourne shell.
description => q{`COMMANDS` is an older form of the
command substitution. } . q{The usage of the POSIX-form
$(COMMANDS) is preferred.} ,
....unless you want to be Bourne compatible ($(...) is not
Bourne).
description => q{The "function NAME { ...; }" form of
the function definition} . q{ is not recommended simply
use NAME() { ...; } to define a function.},
is a kshism. In some AT&T ksh, functions defined like that are
treated differently from the standardly defined ones. Note that
the { ...; } are not necessary. POSIX requires a compound
command. All shells but bash will allow any command.
description => q{"let MATH" is the classic form of the
arithmetic evaluation } . q{command. Bash has an own
compound command for that, which should be used} . q{ if
possible: ": $((MATH))".} ,
Again, "let" is a kshism. $((...)) is the POSIX form not bash's.
In bash, arithmetic expansion should be quoted as it's subject
to word splitting. So either
: "$((MATH))"
or use assignments
var=$((MATH))
description => 'Line is longer than 78 characters,
consider splitting it over' . " multiple lines to
increase readability.",
Why 78?
--
Stéphane
.
- Follow-Ups:
- Re: Announcement: bashcritic
- From: bsh
- Re: Announcement: bashcritic
- From: Teo
- Re: Announcement: bashcritic
- From: Teo
- Re: Announcement: bashcritic
- From: Jan Schampera
- Re: Announcement: bashcritic
- References:
- Announcement: bashcritic
- From: Teo
- Announcement: bashcritic
- Prev by Date: Re: Make unix shell script protected so that noone open and read it
- Next by Date: Re: equal or double equal
- Previous by thread: Announcement: bashcritic
- Next by thread: Re: Announcement: bashcritic
- Index(es):
Relevant Pages
|
