Date:        Wed, 5 Jun 2019 11:06:50 +0200
    From:        Joerg Schilling <[email protected]>
    Message-ID:  <5cf7862a.mNxdelxJXQ1y8/ss%[email protected]>


  | And because I do not like to wait until that time, I believe that
  | there is a need to be able to check whether a shell hides "." and ".."
  | from the glob results.

That's easy now, it is just not free...

(
        umask 077
        TOP=$(mktemp -d "...___${0##*/}") || exit 3
        trap "cd '${PWD}' && rm -fr '${TOP}'" EXIT
        cd "${TOP}" || exit 3
        mkdir a && cd a || exit 3
        case "$(echo .*)" in
        '. ..') exit 2;;
        . | ..) exit 1;;
        '' | '.*')      exit 0;;
        *)      echo "Strange glob!" >&2; exit 3;;
        esac
)
case "$?" in
3)      echo "Sorry... No idea"; exit 1;;
2)      echo ". and .. are included";;
1)      echo "One of . or .. is included!";;
0)      echo ". and .. are excluded";;
esac

Of course, you're more likely to use the result in some
better way than a simple echo (or printf).

This will tell you not only whether the shell includes them,
but whether it includes them when being run in $PWD (if you
need to know some other directory, just cd there as the first
command inside the  ( ) ).

It is harder if you cannot write in the relevant directory, but
not impossible.

When I tested this, mksh and "zsh --emulate sh" both returned 0,
everything else I tried returned 2.   Nothing gave 1 (fortuately)
or 3.  Nothing emitted any diagnostics.   All of the filesystems I
have available have '.' and '..' entries in directories (no, I have
no FAT filesystems!)

And yes, I know that this code assumes that $PWD does not expand
to something containing a ' character....   Fixing that is
irrelevant here.   ($TOP cannot if mktemp works as advertised).

Of course, if your system is stupid enough not to have mktemp(1)
(like a standard POSIX system) then even more complexity would be
needed - or simply get and install a mktemp(1) instead!

More on the topic, I am not really in favour of adding an option
related to this - particularly not a global option that would be
one more thing that would need constant attention and become just
another source of bugs.

If any actual spec change is needed in this area, I'd be happy enough
with either making it unspecified whether '.' and '..' are ever
returned from glob expansions, or simply banning them from ever being
returned (I'd change the NetBSD sh that way if POSIX mandated it,
and perhaps even if just allowed).

I'm even less in favour of this group actually going an inventing an
option for this purpose than I am in having an option for it.  Leave
invention to the implementations, and then if one is proven successful,
then standardise it.

kre

ps: I am even less in favour of any of the other nonsense that has been
proposed here recently as possible changes to the spec, or how sh ought
to behave, or what the language should contain (that is, any of the messages
originally inspired by this discussion.)


Reply via email to