Re: mkdir and ls display

[Bob Proulx]

Pádraig Brady wrote:
> Ngô Huy wrote:
> >     > I had problem with mkdir and ls when I used command:
> >     >
> >     > mkdir "* /" && mkdir "* /etc" && ls.
> >     >
> >     > It only displayed *.
> > 
> >     Note as yet unreleased version of ls will use shell quoting
> >     to give a less ambiguous output:
> > 
> >     $ ls
> >     '* '

With previous and legacy versions you can use -b to quote non-graphic
characters.

  ‘-b’
  ‘--escape’
  ‘--quoting-style=escape’
     Quote nongraphic characters in file names using alphabetic and
     octal backslash sequences like those used in C.

That would show:

  $ ls -b
  *\ 

> >     > If we have hidden directory and use xargs with find to execute some 
> > command, it's security risk. Should we patch it's behavior ?
> > 
> >     I think you're worried about the '*' being expanded?
> >     Or maybe the xargs splitting on the space.

File names will either be internally or externally produced and if
externally produced then they should be treated with the same care of
any external data.  It is always necessary to properly protect any
external input.  If the file names are protected correctly then there
is no need to worry about shell metacharacter expansion and word
splitting.

> >     Not something that mkdir (coreutils) should be worried
> >     about in any case.

Agreed.

> > I see this, but when use mkdir "* /" && mkdir "* /etc", it
> > shouldn't be / in file name, right ?
> 
> I don't see the issue here. mkdir is just passing down to the mkdir syscall
> to create the "* /etc" dir, i.e. the 'etc' dir in the already created '* ' 
> dir.

I think maybe the concern is the '/' *in* the filename?  There are
only two characters that cannot occur in a file name.  That is '/' and
the zero character '\0'.  All others are allowed.  Since the '/' is
not allowed it can never occur in the filename.

What happens instead (and I am a little fuzzy with this description)
is that the '/' forces the file system to treat it as a directory and
if it is a symlink it will dereference through the symlink to the
underlying directory.  Therefore these are equivalent.

  mkdir foo
  mkdir foo/
  mkdir foo//
  mkdir foo///
  mkdir foo////
  ...

> > We try to avoid incident problem, I think we should limit file
> > name's character.

Only '/' and '\0' are not allowed.  All other characters are allowed.

> That would have to be done at the kernel level.

Agreed.

> There have been proposals with POSIX to use a restricted character
> set for file names. 

I often think it would have been nice if whitespace was disallowed.
That would make the traditional shell handling of file names much
easier and no worries about whitespace in file names.  Oh well.

Bob