[comp.sys.att] Funny thing happened to me ... Beware of "$_" and the shell you run

lenny@icus.islp.ny.us (Lenny Tropiano) (05/08/89)

Doing some permission changing today, I goofed .. it had me going for a
while ... I figured I would relay this information, so if someone else goofs
like I did (and it's bound to happen), they'll know what to look for.

Here's what happened ...

I was creating a file in my /usr/mail directory called "LENNY", basically it's
for those BITNET-weirdo sites that like to return mail to ICUS!LENNY, and
then smail barfs on this end and returns the mail.  I place "Forward to lenny"
in that file so that it gets to me ... well, this doesn't have much to do
with my story except for what happened when I was changing permissions.

Normally I run /bin/ksh... so for those ksh people they know what "$_" does.
It basically returns the last argument in the previous command line.  It's
normally used like so...

# chown lenny /usr/mail/LENNY
# chgrp mail $_
# chmod 660 $_

In the last two commands, $_ is substituted with /usr/mail/LENNY, it saves
on those keystokes ...

Well that's normal and dandy for anyone running /bin/ksh, but what happens
if your shell is /bin/sh ...  If you echo $_ while running /bin/sh, you'll
notice it returns /bin/sh.  Now what happened to me...  /bin/sh's group was
changed  to mail, and the permission was 660.  Ut oh.   Well I didn't quite
notice this right away... I just logged out normally, thinking everything
was set.

I returned about 2 hours later and noticed that my screen was blank (that
green dot pattern) [for those wondering, I have an UNIX pc] ... Only thing
was that my phone manager was running, the status manager was running (and
the clock was correct) and the window manager was also running... No login
at all ... this was real weird (I thought at first).  There was no DTR 
(uugetty) on my Trailblazer, and my remote terminal line didn't have a 
getty either.

I figured something got zapped, so I took drastic measures and depressed
the RESET button.  The machine booted up to the point of ...

Version 3.51 ...
Real Memory = 
Available Memory =  
...

Then started doing some massive disk I/O.  I inserted the Floppy UNIX
and RESET again.  Well to make a long story short (I guess it's too late
for that) ... I checked obvious things like /etc/inittab, /lib/shlib,
/etc/rc, missing ... nada.   Well after a few reboots, and testing ... 
I noticed that nothing in /etc/rc was being executed ... Ahhh, I thought
it's a shell script, maybe /bin/sh is munged ... Sure was, at least
permissions were.  

Well that's what happens when you make /bin/sh non-executable ... Oooops.
No flames please, we're only human ...

								-Lenny

-- 
Lenny Tropiano             ICUS Software Systems         [w] +1 (516) 582-5525
lenny@icus.islp.ny.us      Telex; 154232428 ICUS         [h] +1 (516) 968-8576
{talcott,decuac,boulder,hombre,pacbell,sbcs}!icus!lenny  attmail!icus!lenny
        ICUS Software Systems -- PO Box 1; Islip Terrace, NY  11752

richard@uhccux.uhcc.hawaii.edu (Richard Foulk) (05/30/89)

} Normally I run /bin/ksh... so for those ksh people they know what "$_" does.
} It basically returns the last argument in the previous command line.  It's
} normally used like so...
} 
} # chown lenny /usr/mail/LENNY
} # chgrp mail $_
} # chmod 660 $_
} 
} In the last two commands, $_ is substituted with /usr/mail/LENNY, it saves
} on those keystokes ...
} 
} Well that's normal and dandy for anyone running /bin/ksh, but what happens
} if your shell is /bin/sh ...  If you echo $_ while running /bin/sh, you'll
} notice it returns /bin/sh.  Now what happened to me...  /bin/sh's group was
} changed  to mail, and the permission was 660.  Ut oh.   Well I didn't quite
} notice this right away... I just logged out normally, thinking everything
} was set.

Looks like another good reason to stick with csh.  !$ is easier to type
and it displays the substitution so you know what's going on.


Richard Foulk		richard@uhccux.uhcc.hawaii.edu

lenny@icus.islp.ny.us (Lenny Tropiano) (06/01/89)

In article <4038@uhccux.uhcc.hawaii.edu> richard@uhccux.UUCP (Richard Foulk) 
writes:
|>} Normally I run /bin/ksh... so for those ksh people they know what "$_" does.
|>} It basically returns the last argument in the previous command line.  It's
|>} normally used like so...
|>} 
...
|>
|>Looks like another good reason to stick with csh.  !$ is easier to type
|>and it displays the substitution so you know what's going on.
|>
Well I found out in "vi-mode" you can do <ESC>_ and it will do exactly like
the !$ in csh... so ksh is as good ;-)  I'm sure in emacs-mode there is
an equivalent keystroke too..

-Lenny
-- 
Lenny Tropiano             ICUS Software Systems         [w] +1 (516) 582-5525
lenny@icus.islp.ny.us      Telex; 154232428 ICUS         [h] +1 (516) 968-8576
{talcott,decuac,boulder,hombre,pacbell,sbcs}!icus!lenny  attmail!icus!lenny
        ICUS Software Systems -- PO Box 1; Islip Terrace, NY  11752

ignatz@chinet.chi.il.us (Dave Ihnat) (06/01/89)

In article <4038@uhccux.uhcc.hawaii.edu> richard@uhccux.UUCP (Richard Foulk)
writes:

>Looks like another good reason to stick with csh.  !$ is easier to type
>and it displays the substitution so you know what's going on.
>
>
>Richard Foulk		richard@uhccux.uhcc.hawaii.edu

You're kidding.  Right?  Tell me you are.  My biggest complaint with 'csh'
was always that you absolutely cannot count on it being on every system you
may write scripts for, and, well, one of Unix's greatest assets was
portability, right?  Also, I don't know about you, but I always found the
history mechanism rather obscure.  It did offer better interactive user
capabilities than the crufty old Bourne shell, but rather than have to change
to Bourne when writing scripts, and 'csh' when interactive, I used 'sh'.

Now, the Korn shell has everything that the old 'csh' could offer, and more;
and it's becoming as widely distributed as the old Bourne shell.  Csh?  It's
still not released to the Public Domain, or verified as pure BSD code, so
you *still* can't count on it's presence when writing scripts, while you *can*
reasonably conditionalize ksh scripts to be easily runnable under Bourne
shells.

I say, csh is history (pun intended); move on to ksh.  The moral of the story
above should be "Looks like another good reason to stick with ksh."

	Dave Ihnat
	Analysts International Corp.
	aicchi!ignatz || ignatz@homebru.chi.il.us

mveao@cbnews.ATT.COM (eric.a.olson) (06/12/89)

    Another neat feature is that if you su from an account
    with ksh to an account without ksh, '$_' gets set
    to /bin/su.