> This messages appeared at [EMAIL PROTECTED] > > Maybe a special prompt should be produced to stop the problem described > below. The leading "." has got mixed with 2 different meanings: > * hidden files start with "." > * the directory above is ".."
And also the current directory, '.'. > Thinking of pattern matching could lead to the current behaviour. It > may be better to change it. I think you are confused. You have submitted a report, possibly about a bug but I fail to find one in your report, to bug-fileutils which is a mailing list dedicated to the GNU fileutils package. But you seem to be talking about shell wildcard expansion which is not done by fileutils but by your shell, probably /bin/sh, /bin/bash, /bin/ksh, /bin/csh, /bin/tcsh, /bin/zsh, or possibly even a different shell as there are many to choose from. But you did not say which shell you were referring too. However, all of those do filename wildcard expansion so that is probably not important. Perhaps you meant to complain to one of the command line shell folks listed above? Nothing in any of the GNU core utilities of fileutils, sh-utils, textutils does filename expansion. That job is left to the command line shell. The utilities have no power to control filename expansion. [Note that it is possible to turn off filename globbing. In bash that would be using 'set -f' and no more wildcard expansion will be performed. But you will find that none of the normal unix commands work in that mode and that you would need to create an entire new set of commands which did their own wildcard expansion (as in DOS) in order to make that even moderately useable. And then of course it wouldn't be a unix-like operating system. As a lark I decided if that could be made usable. Hmm... To chmod only the dot files without . or .. getting changed. You have to do your own wild card expansion using $() on the command line. Assuming using bash the following works, after a fashion. set -f ls -d $(\ls -A | grep '^\.') chmod go-w $(\ls -A | grep '^\.') The ls -A does not list . or .. and so nothing special needs to be done there. Use \ls to avoid any aliases for ls. Now the grep should only leave normal files left over that begin with a dot. Of course you notice that in order to ls those files you have to use ls to generate the list to be sent to ls! Note that I am not really suggesting this. It is just a diversion.] Bob Part of an upcoming FAQ on this topic, and a mostly canned response: The shell interpreter is expanding the command line glob characters prior to handing the arguments off to your command. This is a simple form of regular expression matching designed to make file name matching easier. This provides a consistent interface to all programs since the expansion code is common to all programs by being in the interpreting shell instead of in the program itself. Commands in UNIX do not see the '.*' or any of the shell metacharacters. Commands see the expanded out names which the shell found matched file names in current directory. The '*' is the "glob" character because it matches a glob of characters. But it only matches files in the current directory. It does not go out and list files in other directories. The shell matches and expands glob characters and hands of the resulting information to the command. You can double check this by using the echo command. This is built into most command shells, for example into bash. Try echo .*. In your example the first would print out .* if nothing matched but would print out all file names that did match. The command would see the result and has no idea that you provided a wild card to match against file names. > At 2001.October.28 12:17 -0500 Sunday, Philip Mak <[EMAIL PROTECTED]> wrote: > > Subject was: (Re: Stupid, stupid > > >I just did a stupid thing to lock myself out of one of my boxes that I > >only have remote ssh access to. I thought I'd share it with you guys so > >that no one else makes the same mistake. > > > >Never type "chmod o-rx .*" when logged in as root, inside root's home > >directory (/root). That will affect .. as well, meaning that the directory > >"/" will no longer be accessible to normal users. > > > >Now I can't ssh into my box (any attempt to connect will say "Cannot find > >root directory" and kick me out) to fix this, so I have to wait for the > >guy who has physical access to the box to fix it. > > > > > >To Unsubscribe: send mail to [EMAIL PROTECTED] > >with "unsubscribe freebsd-questions" in the body of the message > > E-mail: Craig Carey <[EMAIL PROTECTED]> _______________________________________________ Bug-fileutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-fileutils
