arman@CS.UCLA.EDU (01/15/88)
Here is a little csh "misfeature" that I ran into by mistake. When
something is piped into a "csh" built-in command, the "csh" goes
wacko. It behaves the same way under 4.{1,2,3}BSD on vaxen. Here is a
sample:
4% echo | source
source: Too few arguments.
5% Reset tty pgrp from 1406 to 1381
5% jobs
[1] Done echo |
6% jobs
7%
-------
I don't have access to C-Shell source at the moment. Any ideas?
-- Arman Bostani // UCLA Computer Science Department // +1 213-825-3194
3417 Boelter Hall // Los Angeles, California 90024-1596 // USA
arman@CS.UCLA.EDU ...!(ucbvax,rutgers)!ucla-cs!armanalan@cogswell.Jpl.Nasa.Gov (Alan S. Mazer) (08/13/90)
Someone came to me with the following problem and I'm clueless.
If I type (SunOS 4.0.3)
kill `ps | grep a.out | awk '{printf("%d ",$1);}'`
to kill every instance of a.out I get
`ps | grep a.out | awk '{printf("%d ",$1);}'`: Ambiguous.
Any idea why? It's not the $1 (changing that doesn't affect anything), and
it works if the command is in a shell script, or if instead of kill one uses
/bin/kill. It also works great inside the Bourne shell. Using echo instead
of kill produces the expected string of space-separated pid's.
I realize that I'm trying to kill the pid of the grep process also. This is
careless, but apparently not part of the problem since the subshell should
have finished executing by the time the kill starts up. When it does work
correctly, it always reports the grep process as already dead.
So. Does anyone have any ideas?
-- Alan # My aptitude test in high school suggested that
..!ames!elroy!alan # I should become a forest ranger. Sometimes I
alan@elroy.jpl.nasa.gov # wonder if that was not indeed my true calling.mcross@pennies.sw.stratus.com (Matt Cross) (08/14/90)
In article <1990Aug13.151415.14575@elroy.jpl.nasa.gov>, alan@cogswell.Jpl.Nasa.Gov (Alan S. Mazer) writes: |>Someone came to me with the following problem and I'm clueless. |>If I type (SunOS 4.0.3) |> |> kill `ps | grep a.out | awk '{printf("%d ",$1);}'` |> |>to kill every instance of a.out I get |> |> `ps | grep a.out | awk '{printf("%d ",$1);}'`: Ambiguous. |> |>Any idea why? It's not the $1 (changing that doesn't affect anything), and |>it works if the command is in a shell script, or if instead of kill one uses |>/bin/kill. It also works great inside the Bourne shell. Using echo instead |>of kill produces the expected string of space-separated pid's. |> Are you using the shell built-in kill? That would explain the difference. When I tried it a sun here, it said: kill: Arguments should be jobs or process id's. But, I'm using tcsh. It seems to me that the internal commands handle the backquotes differently... That's as much as I could figure out... -- These are my views, and in no way reflect the views of Stratus Computer, Inc. Mail to: mcross@es.stratus.com or profesor@wpi.wpi.edu
bd@hpopd.HP.COM (Bob Desinger) (08/14/90)
> to kill every instance of a.out I get > `ps | grep a.out | awk '{printf("%d ",$1);}'`: Ambiguous. Can you work around this by changing the awk program to generate the kill commands, then piping the awk output to the shell? As in: ps | grep a.out | awk '{print "kill", $1}' | sh -- bd
cudcv@warwick.ac.uk (Rob McMahon) (08/16/90)
In article <8000007@hpopd.HP.COM> bd@hpopd.HP.COM (Bob Desinger) writes: >> to kill every instance of a.out I get >> `ps | grep a.out | awk '{printf("%d ",$1);}'`: Ambiguous. > >Can you work around this by changing the awk program to generate the >kill commands, then piping the awk output to the shell? ... The best workaround is just to use \kill `ps | grep a.out | awk '{printf("%d ",$1);}'` to avoid using the shell builtin. Rob -- UUCP: ...!mcsun!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick INET: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
D. Allen [CGL]) (08/19/90)
I'm concerned about the number of people posting to the Wizards list
who should be posting to comp.unix.questions. This is a Wizards list;
wading through rampant lack of Unix experience is tedious.
Someone is claming that CSH's "Ambiguous" error is due to different
handling of the built-in kill vs. /bin/kill. I think not:
% `echo date`
Sat Aug 18 20:10:09 EDT 1990
% `echo date foo`
`echo date foo`: Ambiguous.
CSH is just stupid about the number of words that are allowed to
expand in a command name generated by back-quotes. It only allows one
word, because it won't re-parse the line for arguments. You get the
same error here:
% date >`echo hi hi`
`echo hi hi`: Ambiguous.
CSH expects single words in funny places, and that's the error you get
if you don't comply. For more entertainment, a huge list of CSH
bugs (4.2BSD, but most still apply) is available via anonymous ftp
from watcgl.waterloo.edu as CSHbugs.Z (compressed). A sample:
Subject: EVAL built-in mishandles and ignores pipes and redirection
eval "who|sort" # the |sort is ignored
eval "who >x" # the >x is ignored
eval "who|date >x" # the pipe is ignored; date goes in x
eval "who|date >x;echo hi" >y
# WHO goes to Y, DATE to X, and HI to tty (!)
Subject: CSH bug with TOSTOP set, using EVAL
If you have STTY TOSTOP set, then
% time eval date
hangs forever, or until you kill it with SIGQUIT.
Subject: CSH loses memory when GLOB applied to external commands.
Either of the following loops will use up all the memory on your computer.
A: % while ( 1 )
? /bin/echo `date`
? end
B: % while ( 1 )
? /bin/echo *
? end
CSH does not free the GLOBbed list of words attached to an
external command name; if one command is followed immediately by
another GLOBbed command, the first GLOB list is not freed.
Subject: Expanding variable with newline generates syntax error
% set x="abc\
def"
% echo "$x"
Unmatched ".
Subject: Expanding quoted variable loses character before newline
% set x="abc\
def"
% echo "$x:q"
ab
def
Subject: Quoting slash in a pathname fouls up GLOB
% echo ."/"*
echo: No match.
% echo "$cwd/"*
echo: No match.
% set x=/
% echo "$x"v*
echo: No match.
% echo "$x"/v*
//vmunix
Subject: Quoting lost in repeated ECHO
% repeat 3 echo "/genvmu*"
/genvmu*
/genvmunix
/genvmunix
Subject: Can't redirect output of "source"
% echo "date" >file
% source file >output
Thu Sep 3 17:47:19 EDT 1987
Etc, etc, etc... I kludged away at all these bugs and managed to fix
them in a local version of 4.2BSD CSH, but the result was not pretty and
I still don't know why many of my fixes work. If the FSF version of bash
only supported transitivity in aliases, I'd move to it in a flash.
--
-IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu
[129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canadachris@mimsy.umd.edu (Chris Torek) (08/20/90)
In article <1990Aug19.011139.13718@watcgl.waterloo.edu> idallen@watcgl.waterloo.edu (Ian! D. Allen [CGL]) writes: >Someone is claming that CSH's "Ambiguous" error is due to different >handling of the built-in kill vs. /bin/kill. (You must mean me here.) >I think not: > > % `echo date` > Sat Aug 18 20:10:09 EDT 1990 > % `echo date foo` > `echo date foo`: Ambiguous. Ah, but this is a symptom of the same thing. >CSH is just stupid about the number of words that are allowed to >expand in a command name generated by back-quotes. This is true; but in kill `echo 1 2` there is exactly one word in the command name. If you try echo `echo 1 2` (for instance) you get 1 2 so it is obvious that >It only allows one word, because it won't re-parse the line for >arguments only under some circumstances (specifically, all those that call the routine `globone' with one of the `words' from the `lexer'). The built-in kill routine (dokill()) is one such place. The routine that runs ordinary (not built in) commands, however, calls globone only for av[0], the command name; it calls tglob and glob on the rest of av. If dokill called tglob and glob in the same way, before marching down the argument list looking for `%'s, the built-in kill would work properly. >same error here: > > % date >`echo hi hi` > `echo hi hi`: Ambiguous. Again, csh calls globone() for an av[] element following a redirection. >CSH expects single words in funny places, and that's the error you get >if you don't comply. In this case, it is probably a good thing: if you typed date > xy* you probably meant to put the output in the (existing) file `xyzzy', not into `xylophone' (which you forgot about) with the argument `xyzzy' passed on to `date'. (After all, you would not want to clobber the file with the information you saved about ordering xylophones. That xylophone is IMPORTANT! :-) ) >For more entertainment, a huge list of CSH bugs (4.2BSD, but most >still apply) is available via anonymous ftp from watcgl.waterloo.edu >as CSHbugs.Z (compressed). Given the csh souce, no doubt it *has* to be kept compressed. :-) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris (New campus phone system, active sometime soon: +1 301 405 2750)