Bug 9110 - wild card asterisk does not function under selected conditions
Summary: wild card asterisk does not function under selected conditions
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: fileutils   
(Show other bugs)
Version: 6.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-02-04 03:39 UTC by John B. Brown
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-02-07 18:26:40 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description John B. Brown 2000-02-04 03:39:31 UTC
ls * returns no such file
ls a* returns no such file
This bug disappears when I su to root from user.
This bug exists for root as root.
This bug disappears for root when I su to user!
This bug also applies to less *, i.e, a directory of files disappears
to the wild card.

The wild card asterisk is not always recognized.
The shell is bash or bash2, and the bug appears with either shell.

So this may not really be a fileutils bug, but that's the command that
bothers me the most. Having to su to get a wild card to work is

One support person suggested this was a result of the PAM system. The
reasoning was my use of a group other than my own group as my login group.
For instance, using wheel or root group in the passwd file. My own
situation is such that the unix convenience of having root group as my own
for this stand alone box is what I want.

Being in northern Wyoming and only connected to the net through a PPP ISP I
don't expect an invasion into my computer. So if PAM is the cause some
elucidation would be welcome as to how I should set my system to eliminate
this really bothersome bug.

Comment 1 John B. Brown 2000-02-04 23:47:59 UTC
This wild card problem also applies to ? as a character wild card. It also
happens any time I use a wild card under the conditions described above; on a
very weird basis. May this also be a bash problem?
Since this original report I've recompiled the kernel and reinstalled it; rpm'd
the kernel in from the CD 1, and compiled linux 2.2.13 w/crypto and installed
that. No change in the wild card condition.
Of course, the support persons original guess may be valid; PAM.
So then what's the solution? I know nothing about PAM.

Comment 2 Bernhard Rosenkraenzer 2000-02-07 18:26:59 UTC
We can't reproduce it anywhere.
Are you sure your user has rx access to the directory you're trying to list?

Comment 3 John B. Brown 2000-02-11 00:57:59 UTC
directories at 777; ls * says no such file. run script, condition
disappers while script runs. su to self, condition disappears. exit from su,
condition reappears.
log in as root, ls * sometimes works, sometimes doesn't. su to user,
condition appears. exit su, condition disappears. enter user directory
(777) su to user, condition appears. exit su condition disappears.
recompile linux w/o networking, condition as above. recompile w/ networking,
condition as above.
logging in to the non networking box caused a PAM message to appear
prior to the prompt appearing, both as root and as user.
What is that???

Comment 4 John B. Brown 2000-02-14 22:09:59 UTC
This bug is not a fileutils bug. Recompiling from various archived source
doesn't change the problem. Recompiling bash from various source also makes no
change. Recompiling the kernel both red hat source and kerneli source makes no
change. I'm going to reenter the problem as a kernel bug.

Comment 5 John B. Brown 2000-02-20 02:30:59 UTC
The problem was with the wild card expander.
alias ls='/bin/ls -aFC $@' worked for 5.2 and 6.0 to expand wild cards and any
text that followed ls.
Now the expander must be $*.
There has been some change! It would be nice to know what. And Why!

Note You need to log in before you can comment on or make changes to this bug.