Re: [list abuse] bug in /bin/csh and /usr/local/bin/tcsh?

Re: [list abuse] bug in /bin/csh and /usr/local/bin/tcsh?

[Duncan Sinclair]

>Q: Why do /bin/csh and /usr/local/bin/tcsh, as part of their startup
>   process, do an lstat of every directory in the root partition where
>   the shell was invoked?

They both do a getwd() call, which does the lstat()s.

The problem is that getwd() needs to search through each directory
as it moves up the file system heirarchy.  If they stumble across
a dead NFS mount, they hang.

For sh, it doesn't try to maintain a "PWD" variable, so it couldn't
care less.

For ksh, and zsh, it first tries to see if "HOME" or "PWD" is
the actual current working directory.  If so, they don't need
to do the getwd() call.

This is *the* feature I was prepared to sell my soul for when
Paul F. was first writing zsh, those many years ago.

The general solution, almost a mantra in some unix news groups,
is that you shouldn't NFS mount *anything* in /.

You might want to try a symlink to a more secure mount point.



Duncan.

RE: [list abuse] bug in /bin/csh and /usr/local/bin/tcsh?

[Amol Deshpande]

It looks like this is done to get the current working directory on
certain sysv systems.
lstat of every dir in the root seems to kick in when the shell is
invoked from a device
different from the root paritition.

this is just from a cursory glance at the source, and I don't know
anything about
system v. caveat emptor etc. etc.

perhaps they are working around an old  bug in the getwd() call ?

-amol
> ----------
> From: 	Mark Borges[SMTP:mdb@cdc.noaa.gov]
> Sent: 	Friday, September 05, 1997 1:16 PM
> To: 	ZSH mailing list
> Subject: 	[list abuse] bug in /bin/csh and /usr/local/bin/tcsh?
> 
> This is certainly not a zsh bug, but since this list has many members
> who know far more about the internals of shells than I, I thought it
> would be a good forum.
> 
> Q: Why do /bin/csh and /usr/local/bin/tcsh, as part of their startup
>    process, do an lstat of every directory in the root partition where
>    the shell was invoked?
> 
> For instance,
> 
>   $ truss /bin/csh -c 'echo foobar' |& grep /archive
>   lstat("./../archive", 0xEFFFC400)               = 0
>   $ truss /usr/local/bin/tcsh -c 'echo foobar' |& grep /archive 
>   lstat("../archive", 0xEFFFE308)                 = 0
>   $ truss /bin/sh -c 'echo foobar' |& grep /archive 
>   $ truss /usr/local/bin/zsh -c 'echo foobar' |& grep /archive 
>   $ truss /bin/ksh -c 'echo foobar' |& grep /archive 
>   $ uname -a
>   SunOS solberg 5.5.1 Generic_103640-08 sun4u sparc SUNW,Ultra-2
>   $
> 
> (Note that zsh, sh, and ksh do not do the lstat. archive is a mount
> point in / for an NFS mounted partition. The script was invoked in a
> subdirectory of /).
> 
> Ordinarily, this is not a big problem. But, one of our users has many
> /bin/csh scripts in his crontab, and when /archive is inaccessible
> (it's a jukebox filesystem that is *very* flaky) his /bin/csh cronjobs
> hang and fail to execute.
> 
> As a potential workaround, we've NFS mounted this volume read-only and
> soft-mounted (it was rw and hard mounted) in the hope that the shell
> will at least start up and execute the script (which has nothing to do
> with /archive). Or will this fail, too?
> 
> Any comments or other suggested work-arounds are most welcome. I've
> tried "don't write scripts in /bin/csh!", but that falls on deaf ears
> ;-).
> 
> -- 
>   -mb-
> 

[list abuse] bug in /bin/csh and /usr/local/bin/tcsh?

[Mark Borges]

This is certainly not a zsh bug, but since this list has many members
who know far more about the internals of shells than I, I thought it
would be a good forum.

Q: Why do /bin/csh and /usr/local/bin/tcsh, as part of their startup
   process, do an lstat of every directory in the root partition where
   the shell was invoked?

For instance,

  $ truss /bin/csh -c 'echo foobar' |& grep /archive
  lstat("./../archive", 0xEFFFC400)               = 0
  $ truss /usr/local/bin/tcsh -c 'echo foobar' |& grep /archive 
  lstat("../archive", 0xEFFFE308)                 = 0
  $ truss /bin/sh -c 'echo foobar' |& grep /archive 
  $ truss /usr/local/bin/zsh -c 'echo foobar' |& grep /archive 
  $ truss /bin/ksh -c 'echo foobar' |& grep /archive 
  $ uname -a
  SunOS solberg 5.5.1 Generic_103640-08 sun4u sparc SUNW,Ultra-2
  $

(Note that zsh, sh, and ksh do not do the lstat. archive is a mount
point in / for an NFS mounted partition. The script was invoked in a
subdirectory of /).

Ordinarily, this is not a big problem. But, one of our users has many
/bin/csh scripts in his crontab, and when /archive is inaccessible
(it's a jukebox filesystem that is *very* flaky) his /bin/csh cronjobs
hang and fail to execute.

As a potential workaround, we've NFS mounted this volume read-only and
soft-mounted (it was rw and hard mounted) in the hope that the shell
will at least start up and execute the script (which has nothing to do
with /archive). Or will this fail, too?

Any comments or other suggested work-arounds are most welcome. I've
tried "don't write scripts in /bin/csh!", but that falls on deaf ears
;-).

-- 
  -mb-