|
Home > Archive > Unix Shell > May 2004 > [Shell behavior] Stupid test on an empty string
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[Shell behavior] Stupid test on an empty string
|
|
|
| After few tests, I have realized that shells have a totally different behavior
when we give them an empty string in interactive mode :
Could somebody explain me why ?
sh:
$ ""
: permission denied
zsh:
[~ (1)]""
zsh: permission denied:
ksh:
$ ""
ksh: : cannot execute - Is a directory
(I dont have any "" directory)
bash:
bash-2.05a$ ""
bash: : command not found
csh:
% ""
: Command not found.
tcsh:
[~ (41)]""
: Command not found.
--
Cedric Coignard
Epitech
Promotion 2008
| |
| Kevin Collins 2004-05-20, 5:37 pm |
| In article <d5e2c604.0405200613.26912a6@posting.google.com>, Dion wrote:
> After few tests, I have realized that shells have a totally different behavior
> when we give them an empty string in interactive mode :
> Could somebody explain me why ?
>
> sh:
> $ ""
>: permission denied
>
> zsh:
> [~ (1)]""
> zsh: permission denied:
>
> ksh:
> $ ""
> ksh: : cannot execute - Is a directory
> (I dont have any "" directory)
This seems to depend on *which* ksh (plus OS, plus environment settings):
ksh88 (HP-UX):
$ ""
ksh: : cannot execute
ksh93 (HP-UX):
$ ""
ksh: : cannot execute [Is a directory]
pdksh (Linux, with FPATH unset):
$ ""
ksh: : cannot execute - Is a directory
pdksh (Linux, with FPATH set to non-existant dir):
$ ""
ksh: : not found
pdksh (Linux, with FPATH set to actual dir):
$ ""
ksh: : function not defined by /some/real/dir
bourne shell (HP-UX - /usr/old/bin/sh):
$ ""
: cannot execute
>
> bash:
> bash-2.05a$ ""
> bash: : command not found
>
> csh:
> % ""
>: Command not found.
>
csh (HP-UX)
% ""
/usr/bin/: Permission denied.
> tcsh:
> [~ (41)]""
>: Command not found.
>
While it is interesting to note the differing messages, what is the point of
the post? Why are you trying to execute ""?
If you are somehow generating a command via script and trying to run "", might
I suggest sticking a ":" in from of each command, like so:
$ : ""
I believe all the shells mentioned support that as a no-op command...
Kevin
| |
|
| > While it is interesting to note the differing messages, what is the point of
> the post? Why are you trying to execute ""?
I'm a student and one of my project is to code a Shell (I should say
'try to' ;))
So I made some tests and I was surprized by the different results, and
asking myself about a different logic in the conception of these
programms.
> I believe all the shells mentioned support that as a no-op command...
Mine doesn't support it yet :P
--
Cedric Coignard
Epitech
Promo 2008
| |
| Barry Margolin 2004-05-22, 10:28 pm |
| In article <d5e2c604.0405201412.564c5ce2@posting.google.com>,
coigna_c@epitech.net (Dion) wrote:
>
> I'm a student and one of my project is to code a Shell (I should say
> 'try to' ;))
>
> So I made some tests and I was surprized by the different results, and
> asking myself about a different logic in the conception of these
> programms.
What's basically happening is that some of the shells are checking
explicitly for this, while others don't treat it as a special case. If
they don't check for it, they treat "" as a filename. They then search
for it in $PATH, by appending it to each directory in this list. So if
$PATH starts with /bin, for instance, they'll try to execute /bin/, but
this will get an error because it's a directory.
Another possibility is that they're not treating it as a special case,
but when they're searching for the program in $PATH, they ignore the
cases where the path entry concatenated with the program name is a
directory. This will cause them to go all the way through $PATH and not
find it.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| Kevin Collins 2004-05-22, 10:28 pm |
| In article <d5e2c604.0405201412.564c5ce2@posting.google.com>, Dion wrote:
>
> I'm a student and one of my project is to code a Shell (I should say
> 'try to' ;))
Well, that is an excellent reason to ask the question, then! Good luck with
that.
> So I made some tests and I was surprized by the different results, and
> asking myself about a different logic in the conception of these
> programms.
>
>
> Mine doesn't support it yet :P
Quick, now's your chance! 
Kevin
| |
| Stephane CHAZELAS 2004-05-22, 10:28 pm |
| 2004-05-20, 22:36(-04), Barry Margolin:
[...]
> What's basically happening is that some of the shells are checking
> explicitly for this, while others don't treat it as a special case. If
> they don't check for it, they treat "" as a filename. They then search
> for it in $PATH, by appending it to each directory in this list. So if
> $PATH starts with /bin, for instance, they'll try to execute /bin/, but
> this will get an error because it's a directory.
[...]
That happens to be a way to run a program with an empty argv[0]:
$ PATH=$PATH:/bin/ps "" -f
UID PID PPID C STIME TTY TIME CMD
chazelas 2088 787 0 12:46:27 pts/1 0:00 -f
chazelas 787 785 0 May 19 pts/1 0:01 /usr/local/bin/zsh
--
Stephane
| |
|
| > Well, that is an excellent reason to ask the question, then! Good luck with
> that.
Thanks
> Quick, now's your chance!
| |
|
| Barry Margolin <barmar@alum.mit.edu> wrote in message news:<barmar-358A7F.22362420052004@comcast.dca.giganews.com>...
> In article <d5e2c604.0405201412.564c5ce2@posting.google.com>,
> coigna_c@epitech.net (Dion) wrote:
>
>
> What's basically happening is that some of the shells are checking
> explicitly for this, while others don't treat it as a special case. If
> they don't check for it, they treat "" as a filename. They then search
> for it in $PATH, by appending it to each directory in this list. So if
> $PATH starts with /bin, for instance, they'll try to execute /bin/, but
> this will get an error because it's a directory.
>
> Another possibility is that they're not treating it as a special case,
> but when they're searching for the program in $PATH, they ignore the
> cases where the path entry concatenated with the program name is a
> directory. This will cause them to go all the way through $PATH and not
> find it.
Ok,
So it will not be so difficult to handle
Thanks,
|
|
|
|
|