Bug 44020

Summary:	lang.csh uses /proc/$$/fd/15, gives error for every script
Product:	[Retired] Red Hat Linux	Reporter:	rhbug
Component:	initscripts	Assignee:	Bill Nottingham <notting>
Status:	CLOSED RAWHIDE	QA Contact:	Brock Organ <borgan>
Severity:	low	Docs Contact:
Priority:	medium
Version:	7.1	CC:	rvokal
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-08-09 00:52:11 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description rhbug 2001-06-09 05:54:18 UTC

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-10 02:28:33 UTC

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 05:34:40 UTC

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-09 00:51:51 UTC

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-09 01:24:25 UTC

Actually, the profile.d code is in csh.login in the roswell beta. So I'm
marking this as resolved there.