Bug 44020 - lang.csh uses /proc/$$/fd/15, gives error for every script
lang.csh uses /proc/$$/fd/15, gives error for every script
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: initscripts (Show other bugs)
7.1
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-06-09 01:54 EDT by rhbug
Modified: 2014-03-16 22:21 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-08-08 20:52:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description rhbug 2001-06-09 01:54:18 EDT
Description of Problem:

/etc/profile.d/lang.csh uses /proc/*/fd/15 on VTs,
which doesn't exist with tcsh/csh

How Reproducible:

run any csh/tcsh script on a VT and get "no such file or directory" error
....every time....

Additional Information:

a script like:
-------------------------
#!/bin/csh
ls -al /proc/$$/fd
-------------------------
	
produces:
dr-x------    0 Jun  9 15:50 .
dr-xr-xr-x    0 Jun  9 15:50 ..
lr-x------   64 Jun  9 15:50 16 -> /utes/wof123
lrwx------   64 Jun  9 15:50 17 -> /dev/pts/0
lrwx------   64 Jun  9 15:50 18 -> /dev/pts/0
lrwx------   64 Jun  9 15:50 19 -> /dev/pts/0

while lang.csh tries to echo to fd/15 (only on VTs) and so
gives an error message with every script.....

17 seems fine ;)
Comment 1 rhbug 2001-06-09 22:28:33 EDT
even using fd/17 there are permission messages on su'd scripts

mebbe the stderr could just be trashed ;)
Comment 2 Bill Nottingham 2001-08-07 01:34:40 EDT
I can't reproduce this here - I create a new user, make tcsh his login sh. fd 15
is always valid.
Comment 3 rhbug 2001-08-08 20:51:51 EDT
15 is valid here for login shells..... but not non-login shells :)

e.g. login shell:
stoke1 17:22 ~ 43> ls -al /proc/$$/fd*
total 0
dr-x------   Aug  8 17:22 ./
dr-xr-xr-x   Aug  8 17:22 ../
lrwx------   Aug  8 17:22 15 -> /dev/tty1
lrwx------   Aug  8 17:22 16 -> /dev/tty1
lrwx------   Aug  8 17:22 17 -> /dev/tty1
lrwx------   Aug  8 17:22 18 -> /dev/tty1
lrwx------   Aug  8 17:22 19 -> /dev/tty1

but if you create a (t)csh script: e.g. /utes/woftam
----------------------------------
#
ls -al /proc/$$/fd*
----------------------------------

then run it on a VT:

stoke1 17:09 ~ 34>/utes/woftam

/proc/1464/fd/15: No such file or directory.
total 0
dr-x------   Aug 8 17:09 .
dr-xr-xr-x   Aug  8 17:09 ..
lr-x------   Aug  8 17:09 16 -> /utes/woftam
lrwx------   Aug  8 17:09 17 -> /dev/tty1
lrwx------   Aug  8 17:09 18 -> /dev/tty1
lrwx------   Aug  8 17:09 19 -> /dev/tty1
you'll get the same output on an xterm too, but no
error message..... as /etc/profile.d/lang.csh contains:

if ( "$TERM" == "linux" ) then
    if ( `/sbin/consoletype` == "vt" ) then
         /bin/echo -n -e '\033(K' > /proc/$$/fd/15
    endif
endif

so error messages only occur on VTs. I saw this constantly as
I am a use-the-console-and-write-a-script-for-everything kind
of guy, but CSH scripts aint that uncommon you know ;)

It aint vital, just very messy to see an error everytime
especially for people who dont know where its coming from.

Happens with kernel 2.4.[3-7] and I'm using base RH 7.1 packages
initscripts-5.83-1.i386.rpm
tcsh-6.10-5.i386.rpm

I spose tcsh could be hacked, or you could add a test to
lang.csh to check not just for vt, but also $SHLVL == 1

then again you might still get the message with su'd scripts
as /etc/csh.cshrc is executed for every shell script and
the ownership of tty is wrong at the time...

or... move the offending code to /etc/csh.login so that
non-login shells dont execute it....

if it's just a problem _I_ have (though I'd have NFI why)
then pls forget about it ;)  



Comment 4 Bill Nottingham 2001-08-08 21:24:25 EDT
Actually, the profile.d code is in csh.login in the roswell beta. So I'm
marking this as resolved there.

Note You need to log in before you can comment on or make changes to this bug.