|
|
donjr wrote:
On Mon, 2005-05-09 at 00:49 -0400, James Ewing Cottrell 3rd wrote:
Bruce is (probably -- I didn't try it, and Joe has already cried
"Uncle") technically correct, but I vote with Joe. Because what he says
(about "[" being a link to "test") is (was) true as well, and because
bash may be unavailable (not on Linux, but elsewhere) and this script
may get thrown at other shells.
For "bash (GNU Bourne-Again SHell)" the commands "[" and "test" are
internally handled unless you change the defaults or override them.
True. But the scrript might be taken to a system without bash and be
thrown at sh. And while this isn't equivalent, it effectively is in most
cases. I think that Joe's and my point was that when we write scripts,
we don't always rely on this new modern behavior. This may be unwise, so
I won't belabor the point.
Still, I have my own viewpoints on the matter. Tests for equalift are
best done by using "case", rather than "if". Thus, a more readable way
would be:
for i in $(ls)
do
case "$i" in
incoming) continue;;
esac
# other commands here
done
But this isn't what the original script was checking for or doing!!!
It only had special (handling) conditions if the file was called
"incoming" and it was also a directory, ie anything else called
"incoming" was to be handled the same as any other name.
Fine. Replace with "incoming) test -d $i && continue;;".
As a matter of fact, having lived thru the Dark Ages with Joe, I would
write it as
ls | while read i
out of fear of blowing my argument list.
??? Please explain as to what advantage this may have?
This has already been done. One other advantage is that t?csh cannot do
this, which is another argument against using it!
As to style, please write "do" and "then" on their own line rather than
attaching them to the first line with a semicolon.
This is just a personal style type of thing.
Yes. And some styles are uglier than others. But you either have taste,
or you don't, so this is difficult to argue.
And as to which a given person prefers depends almost entirely on there
personal programming/training history.
Right. I don't wish to belabor the point beyond stating that it's Ugly.
If anything matter at all, it's the style that the implementors of the
shells used themselves.
Finally, depending on ls being aliased to "ls -F" elsewhere is NOT
KOSHER.
{although as far as "ls" and the "-F" parameter goes, I generally agree
with your above statement.}
That's good, because that is the part of what I said that is Airtight.
If you are going to make/extend the statement/conditions to include the
following:
A shell script must be written to be entirely self-contained. It
may not depend on any external factors, such as external startup scripts
or environment because you never know ho might run it and under what
conditions.
Then I must ask, why is your example written in such a way as to relay
on the possibly EXTERNAL program "ls" and/or not even stating it's full
name, but replying on the PATH {search subsystem} to find this external
program/utility?
{as 'ls' isn't a name of a internal "bash" command}
Sigh. You need to start Hearing What I Mean rather than Reading What I
Say. And Stop Splitting Hairs!
I could not POSSIBLY mean that using external commands were prohibited.
What I DO mean, is Specifically:
[1] It must not depend on any environment variables, *including PATH*.
Yes, every shell script need to include a PATH=/bin:/usr/bin:/wherever
at the beginning. This is necessary for Security as well as Cron Jobs,
where there has (traditionally) been NO environment. A corollary is that
IFS should also be set.
[2] It must not depend on Aliases. One reason is that KSH processes
aliases in such a way as to make them unusable in scripts. Even if it
did, it's bad practice because if [4].
[3] More generally, a script must not depend on any startup scripts
(.cshrc, .kshrc, .bashrc, etc) being run. Indeed, csh, ksh, and bash
include the options -f, -p, and --norc (not sure about that spelling
exactly) to prohibit execution of same. Ditto for /etc/profile and
similar startup scripts.
[4] As to WHY the above is Bad Practice, the "Meaning" of the script
should be independent of the User who executes it. If you import the
User's aliases, functions, and PATHs, you have no assrance that the
script will perform as written.
JIM
_______________________________________________
ma-linux mailing list
ma-linux@xxxxxxx
http://www.tux.org/mailman/listinfo/ma-linux
|
|