Characters in function names
Spiros Bousbouras
in BASH ? Other shells ?
I was assuming that alphanumerical and underscores
are the only ones permitted but I was surprised
recently to see that BASH allows :
Stephane Chazelas
> Which characters can appear in function names
> in BASH ? Other shells ?
As they share the same namespace as command arguments, intuition
would say any character but the NUL character, but YMMV.
> I was assuming that alphanumerical and underscores
> are the only ones permitted but I was surprised
> recently to see that BASH allows :
POSIX allows the same thing as for variable names that is
alnum+_ and must not start with a digit.
zsh allows everything. Even the empty string or the NUL
character (zsh is the only shell to allow NUL bytes where
applicable) are valid function names.
$ ''() echo test
$ ""
test
Other shells may have restrictions, but they would be artificial
as there's no reason at all to put a restriction here.
--
Stephane
Kenny McCormack
Stephane Chazelas <stephane...@yahoo.fr> wrote:
...
>Other shells may have restrictions, but they would be artificial
>as there's no reason at all to put a restriction here.
Other than sanity. And, possible future expansion.
A lot of the problems we currently have with Unix shell scripting
(judging, if nothing else, by the number of posts about it in this NG)
is the allowing of "anything but NUL or '/'" in filenames. Note, in
particular, that this question often takes the form of "I have files in
Windows with spaces/funny-characters in them; how do I deal with them in
Unix?", but the truth is that Windows is significantly *more*
restrictive (not restrictive enough in my view - see below) than Unix.
I'm a strong believer in the idea that long filenames are evil and that,
if we all had it to do over again, they wouldn't be allowed. Instead,
filenames should be limited to something manageable (8.3 being as good
as anything) and then a file would have some kind of extended attribute
attached to it that would be the long name.
Which, of course, is exactly what long filenames are in Windows (this is
precisely so in FAT/FAT32 - effectively so in NTFS). It is also the
idea behind 4DOS's "descriptions".
Janis Papanagnou
> Which characters can appear in function names
> in BASH ? Other shells ?
ksh93r seems to support locale specific non-ASCII characters. See the
release notes...
"Support for processing/handling multibyte locales (e.g., en_US.UTF-8,
hi_IN.UTF-8, ja_JP.eucJP, zh_CN.GB18030, zh_TW.BIG5 etc.) has been
extensively revised, tested, and is now supported even on the language
level (e.g. variable and function identifiers may contain locale
specific codeset characters)."
Besides that there's the '.' (dot) possible as part of a ksh language
specific extension (discipline functions and "structured variables").
Though I was not successful with other interpunctation or blanks in
function names; i.e. apart from some strange behaviour...
$ cat funname
function hello world { echo "'$1' '$2'"; }
function grüßGott { echo "'$1' '$2'"; }
hello world xyz 123
grüßGott abc 0
$ ./funname
'world' 'xyz'
'abc' '0'
...where I would have expected at least a parsing error with the first
function definition.
> I was assuming that alphanumerical and underscores
> are the only ones permitted but I was surprised
> recently to see that BASH allows :
ksh93 seems to not support ':' (colon) in filenames.
Janis
Martin Krischik
> In article <47b05341$0$905$ba4a...@news.orange.fr>,
> Stephane Chazelas <stephane...@yahoo.fr> wrote:
> ...
>> Other shells may have restrictions, but they would be artificial
>> as there's no reason at all to put a restriction here.
>
> Other than sanity. And, possible future expansion.
>
> A lot of the problems we currently have with Unix shell scripting
> (judging, if nothing else, by the number of posts about it in this NG)
> is the allowing of "anything but NUL or '/'" in filenames. Note, in
> particular, that this question often takes the form of "I have files in
> Windows with spaces/funny-characters in them; how do I deal with them in
> Unix?", but the truth is that Windows is significantly *more*
> restrictive (not restrictive enough in my view - see below) than Unix.
If ever "Linux on the Desktop" catches on you can add "KDE / GNOME users
created files with spaces/funny-characters in them ..."
> I'm a strong believer in the idea that long filenames are evil and that,
> if we all had it to do over again, they wouldn't be allowed. Instead,
> filenames should be limited to something manageable (8.3 being as good
> as anything)
Or VMS: 32.32 - a 3 chars name space for extensions could quickly
exhaust. But then file types should be part of the extended attributes
as well.
> and then a file would have some kind of extended attribute
> attached to it that would be the long name.
Yep that is precisely what OS/2 did with it's ".TITLE" extended
attributes - Only OS/2 allowed 250 chars in file names (Case-Retentive,
and no "\n")
> Which, of course, is exactly what long filenames are in Windows (this is
> precisely so in FAT/FAT32 - effectively so in NTFS). It is also the
> idea behind 4DOS's "descriptions".
Indeed - but one should remember that 8.3 name space can quickly exhausted.
Martin
--
mailto://kris...@users.sourceforge.net
Ada programming at: http://ada.krischik.com
Martin Krischik
> ...where I would have expected at least a parsing error with the first
> function definition.
>
>> I was assuming that alphanumerical and underscores
>> are the only ones permitted but I was surprised
>> recently to see that BASH allows :
>
> ksh93 seems to not support ':' (colon) in filenames.
In which case ksh93 can't be used for Wine (http://www.winehq.org/)
maintainance as wine need at the very least one symbolic link named 'c:'
;-) and on most system there will also be a 'd:', 'e:' etc pp link. And
you do have to create them delete them.
Of course I never had problem maintaining them using Z-Shell :-) .
Spiros Bousbouras
wrote:
(referring to ksh)
> Though I was not successful with other interpunctation or blanks in
> function names; i.e. apart from some strange behaviour...
>
> $ cat funname
>
> function hello world { echo "'$1' '$2'"; }
> function grüßGott { echo "'$1' '$2'"; }
>
> hello world xyz 123
> grüßGott abc 0
>
> $ ./funname
> 'world' 'xyz'
> 'abc' '0'
>
> ...where I would have expected at least a parsing error with the first
> function definition.
I'm not particularly surprised that the definition for 'hello world'
works but I'm surprised that the invocation works. I'd sure like
to know how ksh parses the command line.
> ksh93 seems to not support ':' (colon) in filenames.
Surely that guarantees a bug report. I don't have much use
for : in filenames but I consider it completely innocent. I
can kind of accept a shell having trouble handling
control characters in filenames but trouble with anything
else is a serious defect in my book.
Janis
wrote:
> Janis Papanagnou schrieb:
>
> > ...where I would have expected at least a parsing error with the first
> > function definition.
>
> >> I was assuming that alphanumerical and underscores
> >> are the only ones permitted but I was surprised
> >> recently to see that BASH allows :
>
> > ksh93 seems to not support ':' (colon) in filenames.
I meant function names (topic of the thread), not filenames.
> In which case ksh93 can't be used for Wine (http://www.winehq.org/)
Of course ksh supports colons in filenames.
MKS ksh88 even has to rely on that.
Janis
> maintainance as wine need at the very least one symbolic link named 'c:'
> ;-) and on most system there will also be a 'd:', 'e:' etc pp link. And
> you do have to create them delete them.
>
> Of course I never had problem maintaining them using Z-Shell :-) .
>
> Martin
>
> --
> mailto://krisc...@users.sourceforge.net
Janis
> On Feb 11, 6:17 pm, Janis Papanagnou <Janis_Papanag...@hotmail.com>
> wrote:
> (referring to ksh)
>
> I'm not particularly surprised that the definition for 'hello world'
> works but I'm surprised that the invocation works. I'd sure like
> to know how ksh parses the command line.
>
> > ksh93 seems to not support ':' (colon) in filenames.
>
> Surely that guarantees a bug report.
Sorry, that was meant to be "function names" (not filenames).
Janis
Janis Papanagnou
> On Feb 11, 6:17 pm, Janis Papanagnou <Janis_Papanag...@hotmail.com>
> wrote:
> (referring to ksh)
>
>>
>>function hello world { echo "'$1' '$2'"; }
>>
>>
>>$ ./funname
>>'world' 'xyz'
>>
>>...where I would have expected at least a parsing error with the first
>>function definition.
(I forgot to respond to this part...)
> I'm not particularly surprised that the definition for 'hello world'
> works but I'm surprised that the invocation works. I'd sure like
> to know how ksh parses the command line.
Did you notice that, when the function is called, the "second part" of
the function name ('world') is actually considered an argument; so the
function definition seems to just _skip_ the word 'world' between the
_function name_ 'hello' and the opening brace.
Janis
Spiros Bousbouras
wrote:
> On Mon, 11 Feb 2008 03:04:32 -0800 (PST), Spiros Bousbouras wrote:
> > Which characters can appear in function names
> > in BASH ? Other shells ?
>
> As they share the same namespace as command arguments, intuition
> would say any character but the NUL character, but YMMV.
But command arguments don't have a namespace meaning that
the shell doesn't store them anywhere. Or do you mean command
names ? If you mean command (as in executable) names then
it's not completely the same with function names because
with functions the shell has to be able to also parse the
definition correctly. But since you're saying that zsh allows
anything I guess it is possible.
> zsh allows everything. Even the empty string or the NUL
> character (zsh is the only shell to allow NUL bytes where
> applicable) are valid function names.
I wonder how one defines or calls a function whose
name only contains NUL bytes.
> Other shells may have restrictions, but they would be artificial
> as there's no reason at all to put a restriction here.
An argument could be made for not allowing = in a function name
because if you type something like t=5 it's not clear if you mean
an assignment or you want to execute a function called t=5. The
same ambiguity can arise with executable names but executable names
are up to the filesystem and a shell has no control over that.
Spiros Bousbouras
No, embarrassingly I didn't see it. I guess that counts as a bug. BASH
gets it right:
prompt> function qwe rty { echo $1 "---" $2 ; }
bash: syntax error near unexpected token `rty'
prompt> qwe rty () { echo $1 "---" $2 ; }
bash: syntax error near unexpected token `('
Stephane Chazelas
> On Feb 11, 1:53 pm, Stephane Chazelas <stephane_chaze...@yahoo.fr>
> wrote:
>> On Mon, 11 Feb 2008 03:04:32 -0800 (PST), Spiros Bousbouras wrote:
>> > Which characters can appear in function names
>> > in BASH ? Other shells ?
>>
>> As they share the same namespace as command arguments, intuition
>> would say any character but the NUL character, but YMMV.
>
> But command arguments don't have a namespace meaning that
> the shell doesn't store them anywhere. Or do you mean command
> names ? If you mean command (as in executable) names then
> it's not completely the same with function names because
> with functions the shell has to be able to also parse the
> definition correctly. But since you're saying that zsh allows
> anything I guess it is possible.
By name space, I probably meant more something like syntax.
The command to execute is determined from the first argument.
In:
'a b' 'b
d' ''
you have 3 arguments. Those 3 arguments are passed to a command
which is identified thanks to the first one. It might be a
function defined as 'a b'() { ... } or "/usr/bin/a b".
>
>> zsh allows everything. Even the empty string or the NUL
>> character (zsh is the only shell to allow NUL bytes where
>> applicable) are valid function names.
>
> I wonder how one defines or calls a function whose
> name only contains NUL bytes.
$'\0\0'() echo test
or
^@^@() echo test
(Where ^@ are actual NUL characters).
Then you may type:
<Ctrl-Space><Ctrl-Space><Return>
to invoque it for instance.
>> Other shells may have restrictions, but they would be artificial
>> as there's no reason at all to put a restriction here.
>
> An argument could be made for not allowing = in a function name
> because if you type something like t=5 it's not clear if you mean
> an assignment or you want to execute a function called t=5.
= is allowed in command names in every shell. You just need to
escape the "=" so that it's not taken as an assignment.
> The
> same ambiguity can arise with executable names but executable names
> are up to the filesystem and a shell has no control over that.
Yes, so given that there's no limitation for commands, there's
no reason to put any for function names.
--
Stephane
Stephane Chazelas
[...]
> prompt> function qwe rty { echo $1 "---" $2 ; }
> bash: syntax error near unexpected token `rty'
>
> prompt> qwe rty () { echo $1 "---" $2 ; }
> bash: syntax error near unexpected token `('
zsh defines qwe and rty as two copies of the function.
If you wanted to define a "qwe rty" function, you'd do:
"qwe rty"() echo $1 "---" $2
--
Stephane