Where do I start?
-
I have been tasked in a new company with maintaining the Linux servers. To call me a Linux Administrator is something of a stretch. Of the many systems made out of WTF code stuck together with WTF glue, this is one of the gems from the system used to deploy new servers.
The servers which must then be updated manually to get them to the state that they can actually do what they're supposed to.
I don't know which part of this script is the most WTF so I will post the whole thing.
#!/bin/bash if test -z "$WHATAMI" ; then echo "Need variable: \$WHATAMI" >>/dev/stderr sleep 1d fi OLDDIR=`pwd` # For diagnostic purposes... /etc/init.d/sshd start SCRIPTS=`ls -C1 generic/P*.{sh,perl} $WHATAMI/P*.{sh,perl} 2>/dev/null | sort -t / -k2` for i in $SCRIPTS ; do echo "--- $i ---" SCRIPTNAME=`basename $i` SCRIPTDIR=`echo $i | sed "s#/$SCRIPTNAME"'$##'` cd $SCRIPTDIR echo "about to start $SCRIPTNAME" >> /tmp/whereami #sleep 3600 if echo "$SCRIPTNAME" | grep -q '\.sh$' ; then sh $SCRIPTNAME 2>/tmp /$SCRIPTNAME.stderr > /tmp/$SCRIPTNAME.stdout ; fi if echo "$SCRIPTNAME" | grep -q '\.perl$' ; then perl $SCRIPTNAME 2>/tmp /$SCRIPTNAME.stderr > /tmp/$SCRIPTNAME.stdout ; fi cd $OLDDIR done
-
While I've had the misfortune of working with bash in the past I don't get this. It's my brain, it reacts to bash like an allergy. Anyone care to explain the WTF?
-
@DOA said:
Anyone care to explain the WTF?
It's a pretty simple script. It uses ls to get a listing of all .sh and .perl scripts in two directories, then it loops through these scripts, executing them with the appropriate interpreter and routing their output to files.As for the WTFs, I'm not a bash guru, but I do know there are much easier ways to loop through directories and parse file names than this. I don't really see how this script alone can mess up a system, though. I could be missing something.
-
@Welbog said:
executing them with the appropriate interpreter
Well there's one WTF. The first line of the (called) script itself is supposed to indicate the interpreter to be used - the code posted uses a file extension to differentiate.
-
@PJH said:
@Welbog said:
executing them with the appropriate interpreter
Well there's one WTF. The first line of the (called) script itself is supposed to indicate the interpreter to be used - the code posted uses a file extension to differentiate.The #! line of each called script does, correctly, indicate which interpreter to use. Whoever wrote this masterpiece decided it wasn't to be trusted. Or something.
-
Simply using shebangs in the scripts would solve a lot of this. Bash scripts are suppused to begin with #!/usr/bin/bash, and Perl scripts with #!/usr/bin/perl. This is bullshit.
Then there's that bit about sleeping for one day if the variable isn't set. It seems to me that exit(1) would be a more appropriate response.
BASH isn't that bad to write or work with, but, like any language, if you don't know what you're doing*, you'll generate WTFs by the barrel.
(* by which I mean logically, as well as linguistically)
-
@Critter said:
Bash scripts are suppused to begin with #!/usr/bin/bash, and Perl scripts with #!/usr/bin/perl.
More like #!/bin/bash (every distro I've used has bash in /bin) and #!/usr/bin/env perl (Some shove perl in /usr/local/bin/, others in /usr/bin/)
-
Well, one of the more major WTFs in this is that it's starting sshd 'for diagnostic purposes', and not stopping it afterwards, possibly introducing a security hole (at least, it's causing sshd to run when the user wouldn't necessarily expect it to). Actually, even starting it and stopping it again would be a WTF. The commented out sleep 3600 does not inspire me with confidence (why was it there in the first place, and if it is there for a reason why would commenting it out help?). A more minor WTF is using fixed /tmp/ names (although I'm occasionally guilty of this myself), and then not actually looking at the files afterwards (which is more of a problem), and also the line breaks in the message above (putting them in the middle of pathnames is not helpful). I think there are others here, too.
-
@ais523 said:
Well, one of the more major WTFs in this is that it's starting sshd 'for diagnostic purposes', and not stopping it afterwards, possibly introducing a security hole (at least, it's causing sshd to run when the user wouldn't necessarily expect it to).
The "user" is an administrator who is setting the server up: sshd should be started . I guess the "for diagnostic purposes" comment isn't really that useful, but that's not a huge deal.
