Weird things in csh (and kernel?)

Weird things in csh (and kernel?)

Post by Maarten Litmaa » Fri, 02 Feb 1990 23:52:00



Has anyone noticed the following oddities?
1)
        % a.out < a.out
        a.out: Text file busy.
        %

Why shouldn't a process be able to read its text file?
2)
        % cat ~/.cshrc
        echo echo hello
        % cp /bin/echo .
        % ./echo > echo
        hello: Command not found.
        % cat echo
        echo hello
        hello
        %

What kinda weird thing is going on here?
Shouldn't there be an error message "Text file busy."
in this case?
--


 
 
 

Weird things in csh (and kernel?)

Post by Sjoerd Mullend » Fri, 02 Feb 1990 11:17:00



>Has anyone noticed the following oddities?
>1)
>    % a.out < a.out
>    a.out: Text file busy.
>    %

If you are debugging a.out then this could happen.  Especially if you have set
breakpoints.

Quote:>Why shouldn't a process be able to read its text file?

It can!

Quote:>2)
>    % cat ~/.cshrc
>    echo echo hello
>    % cp /bin/echo .
>    % ./echo > echo
>    hello: Command not found.
>    % cat echo
>    echo hello
>    hello
>    %

When executing the command "./echo > echo" the shell will first create the
file echo.  It then tries to exec ./echo.  The kernel refuses (it's not an
object anymore, it an empty file) and the shell will start interpreting the
script.  The shell will fork off a new shell to do the work.  This new shell
will first execute ~/.cshrc which contains the command "echo echo hello".
So the string "echo hello" is echoed into the output file (echo).  Then the
shell really starts executing the script.  It now contians the string
"echo hello", so that command is executed.  The result (the string "hello")
is appended to the output file (that file was never closed or re-created).
After that the next line of the script is "hello" and the shell is not able
to find the command.  Hence the error message.

Quote:

>What kinda weird thing is going on here?
>Shouldn't there be an error message "Text file busy."
>in this case?

Nothing that cannot be explained.

Why was this cross-posted to comp.unix.wizards?
--
Sjoerd Mullender

When this doesn't work try sending via seismo.css.gov or mcvax.uucp.

 
 
 

Weird things in csh (and kernel?)

Post by Maarten Litmaa » Fri, 02 Feb 1990 22:18:00



\>   % a.out < a.out
\>   a.out: Text file busy.
\>   %
\If you are debugging a.out then this could happen.  Especially if you have set
\breakpoints.

I was NOT debugging a.out...

\>...
\>   % ./echo > echo
\>...
\When executing the command "./echo > echo" the shell will first create the
\file echo.  It then tries to exec ./echo.  The kernel refuses (it's not an
\object anymore, it an empty file) and the shell will start interpreting the
\script.  The shell will fork off a new shell to do the work.  This new shell
\will first execute ~/.cshrc which contains the command "echo echo hello".

Isn't it a BOURNE shell that is forked off, which won't execute ~/.cshrc?

\Why was this cross-posted to comp.unix.wizards?

Possible kernel bugs are detected by wizards only, I guess.
--


 
 
 

Weird things in csh (and kernel?)

Post by Fai L » Sat, 03 Feb 1990 00:49:00



>Has anyone noticed the following oddities?
>1)
>    % a.out < a.out
>    a.out: Text file busy.
>    %

        This is not as bad as this,

        cat file | grep john > file

        There will be nothing withsoever in file "file". UNIX is kinds
strange when you put the same file name at both "ends" of a pipeline or
redirect. Aviod doing it or sooner or later you'll find out some files
you're working on would be strangely deleted against your wish. Speaking
from experience here.

Quote:>Why shouldn't a process be able to read its text file?
>2)
>    % cat ~/.cshrc
>    echo echo hello
>    % cp /bin/echo .
>    % ./echo > echo
>    hello: Command not found.
>    % cat echo
>    echo hello
>    hello
>    %

        Find the source code echo.c, compile it, put the executable in you
directory, and the problem would go away. The only explanation
I can give for the phenomonen is that for some reason csh wants to
parse .cshrc, and somehow thinks hello is a command. I'm using
tcsh in /usr/local/bin and I got the error message "/bin/tcsh: not
found" until I restarted with csh did I got the behavior you
described.

Fai Lau
SUNY at Buffalo (The Arctic Wonderland)
UU: ..{rutgers,ames}!sunybcs!ugfailau

 
 
 

Weird things in csh (and kernel?)

Post by Patrick Barr » Fri, 02 Feb 1990 08:41:00



>Has anyone noticed the following oddities?
>1)
>    % a.out < a.out
>    a.out: Text file busy.
>    %
>Why shouldn't a process be able to read its text file?

   I can't reproduce this under Ultrix 1.2.

Quote:>2)
>    % cat ~/.cshrc
>    echo echo hello
>    % cp /bin/echo .
>    % ./echo > echo
>    hello: Command not found.
>    % cat echo
>    echo hello
>    hello
>    %

>What kinda weird thing is going on here?
>Shouldn't there be an error message "Text file busy."
>in this case?

This is actually pretty simple.  When you redirect output to "echo",
the file gets overwritten *before* "./echo" is executed.  So, it ends
up trying to execute an empty file.  Since it doesn't have a valid
magic number, and the execute bits are set (copying /bin/echo left
them set, and overwriting the file didn't change that), it's assumed
to be a shell script.  Your .cshrc file gets executed, echoing
"echo hello" using the C-shell's built-in echo.  That goes into
the file "./echo", and the shell then starts to execute commands from
"./echo".  (Why isn't the Bourne shell used to do this?  The file does
not start with "#!/bin/csh")  That file now contains "echo hello", so
the shell's "echo" echoes "hello".  Remember, standard output is still
the "./echo" file, so that gets tacked on to the end.  The shell then
reads the next command, which is "hello", and it complains "Command not
found."

--Pat.

 
 
 

Weird things in csh (and kernel?)

Post by Doug Gwy » Fri, 02 Feb 1990 02:45:00



>Isn't it a BOURNE shell that is forked off, which won't execute ~/.cshrc?

It ought to be (since otherwise the behavior of a shell script would
depend on which shell the invoker happened to be using), but most Cshell
implementations I've run across think that anonymous scripts should be
interpreted by (an instance of) them.
 
 
 

Weird things in csh (and kernel?)

Post by Kenneth Almqui » Fri, 02 Feb 1990 21:40:00


Quote:> % a.out < a.out
> a.out: Text file busy.
> %

The basic problem that the "text file busy" error was designed to solve
is this.  When several copies of the same program are run concurrently,
UNIX will only create a text segment for the first copy.  Subsequent
invocations of the program will reuse this text segment rather than
creating a new one.  The problem with this approach is that if a program
is modified, the system may continue to reuse the old version of the
text segment rather than using the new version.  This problem was avoided
by making the following actions illegal:

        1)  Opening a file that is being executed.
        2)  Executing an open file.
        3)  Deleting the last link to a file that is being executed.

So when you say "a.out < a.out", the shell opens a.out and then tries
to execute it.  The attempt to execute it fails due to rule 2.  You
are presumably running some version of 2 BSD; both 4 BSD and System V
have relaxed rules 1 and 2 to allow files that are being executed to
be opened for reading and vice versa.

My view is that these rules should be eliminated all together.  They are
inconvenient, since they make program installation harder.  They are
inconsistent with the rest of the design of the UNIX file system calls,
which permits any operation to be performed at any time (even operations
like deleting other people's current working directories).  It is a
bit simpler to enforce these rules than to design things so that they
are unnecessary, but given the growth of the kernel in recent years it
is hard to justify taking some of the complexity of supporting shared
text out of the kernel and pushing it onto the users.
                                Kenneth Almquist

 
 
 

Weird things in csh (and kernel?)

Post by r.. » Fri, 02 Feb 1990 19:39:00


Quote:>Has anyone noticed the following oddities?
>1)
>    % a.out < a.out
>    a.out: Text file busy.

It is behaving that way because it was loaded that way.  On our 11/44,
running 2.9bsd, any program compiled with "-i" or "-n" will display that
behavior.  Try looking at the man entry of "ld" to get hints on what
options might do this.

        == kwthomas ==

 
 
 

Weird things in csh (and kernel?)

Post by Maarten Litmaa » Fri, 02 Mar 1990 04:26:00




\>Isn't it a BOURNE shell that is forked off, which won't execute ~/.cshrc?
\
\It ought to be (since otherwise the behavior of a shell script would
\depend on which shell the invoker happened to be using), but most Cshell
\implementations I've run across think that anonymous scripts should be
\interpreted by (an instance of) them.

% cat gnome
alias   l       ls -l
% ls -l gnome
-rwxr-xr-x 1 3754         14 Mar  1 14:20 gnome
% gnome
gnome: alias: not found
%

This shows that normally a Bourne shell indeed is forked off...
--


 
 
 

Weird things in csh (and kernel?)

Post by Maarten Litmaa » Fri, 02 Mar 1990 16:53:00


\> % a.out < a.out
\> a.out: Text file busy.
\> %
\
\...  You
\are presumably running some version of 2 BSD; both 4 BSD and System V
\have relaxed rules 1 and 2 to allow files that are being executed to
\be opened for reading and vice versa.

Our version is 4.1BSD!
--


 
 
 

Weird things in csh (and kernel?)

Post by Bob Le » Sat, 03 Mar 1990 00:51:00


Quote:>Isn't it a BOURNE shell that is forked off, which won't execute ~/.cshrc?

Based on experimentation, csh's test is something like:

        if I can read from the file and the first character is not #
                give it to sh
        else
                give it to csh

Thus a zero-length file, as a degenerate case, is run by the csh.
The only difference between csh and sh for a zero-length file is,
of course, that .cshrc is sourced.

                Bob Lenk
                {ihnp4, hplabs}!hpfcla!rml

 
 
 

Weird things in csh (and kernel?)

Post by Richard Tob » Fri, 02 Mar 1990 15:25:00


   [discussion of which shell csh uses to run a script]

Csh [BSD 4.2] assumes that it should run /bin/sh if and only if
(1) exec() fails with ENOEXEC
(2) there isn't an alias for shell
(3) it can read the first character of the file
(4) that character isn't '#'

Thus empty files get run with csh, because (3) is violated.

-- Richard
--


Edinburgh University.                  UUCP:  ...!ukc!ed.ac.uk!R.Tobin

 
 
 

1. weird csh thing

anyone care to explain??  (I`m in csh)

$ set p = "w | tail +3 "
$ echo $p
w | tail +3
$ $p
Usage: w [ -hlsuw ] [ user ]
$ w | tail +3
benjo    ttyp3    10:13pm           41      4  -sh
benjo    ttyp4    10:17pm         3:22      4  -csh
$ exit
$ exit

Process shell finished

shouldn't "$p" have the same effect as "w | tail +3" ?

        -rj
--
--------------------------------------------------------------------------------
Ranjan Bagchi - At Large.  Well Kinda.  |  what kind of person

        caen,                           |  just to write haiku?
        math.lsa].umich.edu             |  
--------------------------------------------------------------------------------

2. ip_masq_ftp

3. Weird thing happening with kernel 2.5

4. Process data

5. (newbie) weird thing with linux applications

6. IFCICO

7. weird ant things

8. Install problem

9. XV does -weird- things

10. Weird Thing: sb module hangs every 2nd boot?

11. weird qconfig thing

12. Weird Ping, weird FTP, weird Telnet... HELP!!!

13. Q:how to write things to stderr in a csh script?