Bug #243

weird behavior in the shell

Added by swildner about 8 years ago. Updated over 3 years ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

Hi,

I'm not sure if this is a 'real' bug but I'm curious if anyone knows the
cause. Check this:

zoot# echo $PATH
/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/pkg/bin:/usr/pkg/sbin:/usr/pkg/xorg/bin:/home/s/bin
zoot# pwd
/usr/src/sys/dev/disk/md
zoot# .
/usr/sbin/.: Permission denied.
zoot# cd /
zoot# .
/usr/sbin/.: Permission denied.

In other words: The strange thing is that whereever I type . on the csh
prompt, I get the /usr/sbin/.: message regardless of what my current
directory is.

On a Solaris system I get ".: Permission denied." which is what I'd
expect rather.

So, can anyone enlighten me why DragonFly behaves like that?

Sascha

History

#1 Updated by qhwt+dfly about 8 years ago

On Sat, Jul 15, 2006 at 09:40:52AM +0200, Sascha Wildner wrote:
> I'm not sure if this is a 'real' bug but I'm curious if anyone knows the
> cause. Check this:
>
> zoot# echo $PATH
> /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/pkg/bin:/usr/pkg/sbin:/usr/pkg/xorg/bin:/home/s/bin
> zoot# pwd
> /usr/src/sys/dev/disk/md
> zoot# .
> /usr/sbin/.: Permission denied.
> zoot# cd /
> zoot# .
> /usr/sbin/.: Permission denied.
>
> In other words: The strange thing is that whereever I type . on the csh
> prompt, I get the /usr/sbin/.: message regardless of what my current
> directory is.
>
> On a Solaris system I get ".: Permission denied." which is what I'd
> expect rather.
>
> So, can anyone enlighten me why DragonFly behaves like that?

I observed that the same thing happens on tcsh-6.12-2 on RedHat Linux 8.0;
the consistency is that it's always the third component in $PATH that is
prefixed to `.' in the error message.

Cheers.

#2 Updated by corecode about 8 years ago

can we close this?

#3 Updated by swildner about 8 years ago

Nope.

Sascha

#4 Updated by corecode about 7 years ago

can we close this?

#5 Updated by corecode over 5 years ago

can we close this?

#6 Updated by corecode over 5 years ago

can we close this?

#7 Updated by swildner over 5 years ago

Nope.

Sascha

#8 Updated by tuxillo over 3 years ago

Hi,

I think tcsh tries to execve() to path "."

execve(2) manpage says:

[EACCES] The new process file is not an ordinary file.

Cheers,
Antonio Huete

Also available in: Atom PDF