rsh (remote shell) -- undocumented(?) feature(?)
Tony Facca
fsfacca at AVELON.LERC.NASA.GOV
Thu Aug 30 00:01:01 AEST 1990
In article <1406 at contex.UUCP> bill at contex.UUCP (Bill Phillips) writes:
>
>I just discovered an apparently undocumented feature of the remote
>shell rsh (not to be confused with the restricted shell of the same
>name). rsh imposes a umask of 022 on all programs run through it.
This is not necessarily true. The Berkeley rsh command imposes whatever
umask is imposed by the remote machine. When you issue the rsh command
it assumes the environment of the remote host.
>Questions:
>
> - might this be under the control of some configuration file?
> I have definitely determined that neither ~/.profile nor
> /etc/profile was responsible.
>
I don't use the Bourne Shell so I don't know if this works for sh or not. If
your default shell is the C Shell (check the /etc/passwd file, last field) on
the remote machine, then rsh commands will invoke the .cshrc file in your
home directory. If you set a umask in this file, it will be the umask used
by the command which is executed.
> - if this is a known "feature", is there some flag for rsh,
> or some other way of turning it off (other than prepending
> "umask 0;" to every command line sent through rsh)?
>
As you have determined, since the .cshrc file is executed by rsh each time
you pass a command to the remote machine, you must either change it in the
.cshrc file or keep doing the 'umask 0' each time. You can, of course string
multiple commands together in an rsh:
rsh remote_host 'echo who ; who ; echo date ; date'
To test the umask do this:
rsh remote_host 'umask ; umask 0 ; who ; date ; umask'
When you do the last umask, it should report 0. Therefore, the 'who' and
'date' commands run with a umask of 0.
Hope this helps some.
--
-----------------------------------------------------------------------------
Tony Facca | fsfacca at avelon.lerc.nasa.gov | phone: 216-433-8318
-----------------------------------------------------------------------------
You are at Witt's end. Passages lead off in *all* directions.
More information about the Comp.sys.sgi
mailing list