Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

ksh globbing (bash extended globbing)

46 views
Skip to first unread message

Janis Papanagnou

unread,
Dec 4, 2016, 5:18:59 PM12/4/16
to
Taken as patterns @(foo|bar) and *(foo|bar) differ; the latter matches
(besides "foo" and "bar") also an empty argument "".

Given how the ksh and bash shell behave with "extended" globbing I had
always considered and used *(foo|bar) and @(foo|bar) interchangeably.
I wonder, though, why in case those patterns are used in _globbing_ the
"empty case" (no file matches) will not be covered by *(foo|bar). The
implemented (default) behaviour is to expand the pattern *(foo|bar) to
the string "*(foo|bar)" if there's no match.[*]

I see there's an argument that "no file" is not the same as a file with
an empty file name. But given that it's not possible to create such an
"unnamed" file it could be useful to use *(...) to prevent the error
message that is displayed with @(...) in case there's no match, instead
of producing an error message.

Thoughts?

Ksh and Bash behave the same in that respect, so there might be some
rationale for the implemented behaviour. (Or maybe bash just copied the
ksh behaviour. Anyway.) Any ideas?

Janis

[*] Yes, in bash, there's also the 'nullglob' and you can use that to
control the behaviour of how non-existing files are handled. But since
we don't have that in ksh (AFAIK) I'm interested in rationaled for the
basic question why the globbing behaviour had been defined the way it is.

0 new messages