typeset -i in Linux
alexvai
I have this command in ksh:
1. typeset -i INTEGER
INTEGER=aaa
in all platforms except of Linux it is failing and return exit code
1
Why in Linux it is not failing? i must it for my number tests
2. The same for printf command. Only in Linux the bellow command is
not failing:
printf "%d" aaa
Thanks a lot.
shell - ksh
uname -a:
Linux illin025 2.6.18-92.1.22.el5 #1 SMP Fri Dec 5 09:28:22 EST 2008
x86_64
Janis Papanagnou
Most probably you have a ksh93 on Linux, and maybe old ksh88 on "all
[other] platforms".
The point with your examples is that in older shells you have (in most
cases) to dereference variable access using a $, like...
INTEGER=$aaa
printf "%d" "$aaa"
Ksh93 handles that more liberally. But mind that not using $x in
places where the variable value of x is required is non-standard.
Janis
Bill Marcum
> Hi,
>
> I have this command in ksh:
>
> 1. typeset -i INTEGER
>
> INTEGER=aaa
>
> in all platforms except of Linux it is failing and return exit code
> 1
>
> Why in Linux it is not failing? i must it for my number tests
>
shell.
>
> 2. The same for printf command. Only in Linux the bellow command is
> not failing:
>
> printf "%d" aaa
>
What error message do you get?
>
> Thanks a lot.
>
> shell - ksh
> uname -a:
> Linux illin025 2.6.18-92.1.22.el5 #1 SMP Fri Dec 5 09:28:22 EST 2008
> x86_64
--
Year, n.:
A period of three hundred and sixty-five disappointments.
-- Ambrose Bierce, "The Devil's Dictionary"
Alexvai
> On 2010-11-18, alexvai <alexva...@gmail.com> wrote:> Hi,
>
> > I have this command in ksh:
>
> > 1. typeset -i INTEGER
>
> > INTEGER=aaa
>
> > in all platforms except of Linux it is failing and return exit code
> > 1
>
> > Why in Linux it is not failing? i must it for my number tests
>
> The "ksh" in Linux is often pdksh, while other systems use the "real" Korn
> shell.
>
>
>
> > 2. The same for printf command. Only in Linux the bellow command is
> > not failing:
>
> > printf "%d" aaa
>
> What error message do you get?
This is the problem, that i don't get errr message in printf "%d" aaa
I want to see error message like in other platforms :)
Jerry Peters
So what shell are you using?
Linux indigo 2.6.35.8 #70 SMP PREEMPT Sat Oct 30 10:34:45 EDT 2010
i686 Intel(R) Atom(TM) CPU N270 @ 1.60GHz GenuineIntel GNU/Linux
~$ printf %d aaaa
-bash: printf: aaaa: invalid number
Jerry
Alan Curry
Jerry Peters <je...@example.invalid> wrote:
>
>So what shell are you using?
>
>Linux indigo 2.6.35.8 #70 SMP PREEMPT Sat Oct 30 10:34:45 EDT 2010
>i686 Intel(R) Atom(TM) CPU N270 @ 1.60GHz GenuineIntel GNU/Linux
>~$ printf %d aaaa
>-bash: printf: aaaa: invalid number
I can reproduce the lack-of-error message:
$ printf %d\\n aaa
0
$ echo $SHELL
/bin/zsh
$ wrong - I logged in with zsh but then ran ksh. this is ksh
ksh: wrong: not found [No such file or directory]
$ echo $KSH_VERSION
$ echo $KSH
$ echo $VERSION
$ set|egrep -i 'ksh|version'
ENV='$HOME/.kshrc'
$ stupid ksh does not want to tell me its version
ksh: stupid: not found [No such file or directory]
$ ^D
Anyway, dpkg -l says
Name Version Description
==============-==============-============================================
ksh 93s+20080202-1 The real, AT&T version of the Korn shell
So this is an AT&T ksh of some unknown vintage. It won't tell me the version
number in the package database only narrows it down to a 15-year range.
Forget the printf bug. ksh people, fix your version identification problem!
--
Alan Curry
Icarus Sparry
So you know enough to expect that 'echo $SHELL' will magically determine
the current shell you are running, but you don't know enough to be able
to read the manual page for the shell. It would tell you that
echo ${.sh.version}
would give you the version information you seek. However it will almost
certainly tell you that it is the Feb 2nd, 2008 release, which is version
"s+". It is not hard to guess this from a string like 93s+20080202-1.
There are other ways to display the version if you have either emacs or
vi editing modes enabled.
Alan Curry
Icarus Sparry <i.spa...@gmail.com> wrote:
>On Sat, 20 Nov 2010 22:10:42 +0000, Alan Curry wrote:
>>
>> Anyway, dpkg -l says
>>
>> Name Version Description
>> ==============-==============-
>============================================
>> ksh 93s+20080202-1 The real, AT&T version of the Korn shell
>>
>> So this is an AT&T ksh of some unknown vintage. It won't tell me the
>> version number in the package database only narrows it down to a 15-year
>> range.
>
>So you know enough to expect that 'echo $SHELL' will magically determine
>the current shell you are running, but you don't know enough to be able
>to read the manual page for the shell. It would tell you that
Well I didn't set SHELL=/bin/zsh manually. It did that itself. ksh just left
the wrong value there, which seems like it could be dangerous. This isn't a
variable I've used often though.
>
> echo ${.sh.version}
Now that is interesting. So the "set" builtin is broken. When run without
arguments, it's supposed to list all variables, but it didn't list that one.
>
>would give you the version information you seek. However it will almost
>certainly tell you that it is the Feb 2nd, 2008 release, which is version
>"s+". It is not hard to guess this from a string like 93s+20080202-1.
The "93" part is as clear to me as the "2008" part. How do I know which one
to believe?
--
Alan Curry
Icarus Sparry
> In article <4ce84fea$0$22118$742e...@news.sonic.net>, Icarus Sparry
> <i.spa...@gmail.com> wrote:
>>On Sat, 20 Nov 2010 22:10:42 +0000, Alan Curry wrote:
>>>
>>> Anyway, dpkg -l says
>>>
>>> Name Version Description
>>> ==============-==============-
>>============================================
>>> ksh 93s+20080202-1 The real, AT&T version of the Korn shell
>>>
>>> So this is an AT&T ksh of some unknown vintage. It won't tell me the
>>> version number in the package database only narrows it down to a
>>> 15-year range.
>>
>>So you know enough to expect that 'echo $SHELL' will magically determine
>>the current shell you are running, but you don't know enough to be able
>>to read the manual page for the shell. It would tell you that
>
> Well I didn't set SHELL=/bin/zsh manually. It did that itself. ksh just
> left the wrong value there, which seems like it could be dangerous. This
> isn't a variable I've used often though.
You will probably find that it is "login" that is setting the variable
(or sshd if you are logging in via ssh), rather than zsh that sets the
variable, or else the variable is set only if it is not already set. It
is hard to see why this is dangerous, it strikes me as much more risky if
variables magically get changed. Consider what would happen if you use
the facility in an editor (say vi or emacs) to run a shell command on a
region of text. One does not want the environment altered for this case.
(I am not sure if I like that Posix shells set the PWD variable
explicitly).
>> echo ${.sh.version}
>
> Now that is interesting. So the "set" builtin is broken. When run
> without arguments, it's supposed to list all variables, but it didn't
> list that one.
set prints all variables that do not have the NV_NOPRINT attribute set.
>>would give you the version information you seek. However it will almost
>>certainly tell you that it is the Feb 2nd, 2008 release, which is
>>version "s+". It is not hard to guess this from a string like
>>93s+20080202-1.
> The "93" part is as clear to me as the "2008" part. How do I know which
> one to believe?
The "93" defines the language, in the same way that in the same way that
for perl "perl5" is a different language to "perl4". So you should
believe both the "93" and the "2008"
Seebs
> The "93" part is as clear to me as the "2008" part. How do I know which one
> to believe?
Ahh, you Just Have To Know (tm).
AT&T ksh comes in two primary families: ksh88 and ksh93. ksh93 is under
active development, and continues to be updated as recently as 2008.
The "93" is like saying gcc supports "C90" or "C99".
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
Alan Curry
Seebs <usenet...@seebs.net> wrote:
>On 2010-11-21, Alan Curry <pac...@kosh.dhis.org> wrote:
>> The "93" part is as clear to me as the "2008" part. How do I know which one
>> to believe?
>
>Ahh, you Just Have To Know (tm).
>
>AT&T ksh comes in two primary families: ksh88 and ksh93. ksh93 is under
>active development, and continues to be updated as recently as 2008.
>The "93" is like saying gcc supports "C90" or "C99".
But the latest release is not called "gcc99-2010". That would be stupid.
Anyway I was just trying to say look, here's a ksh that reproduces the bug in
the original report, and finding its version string was harder than expected.
I thought my post would possibly be helpful despite being incomplete.
zsh has $ZSH_VERSION; bash has $BASH_VERSION; even posh has $POSH_VERSION;
'set|grep VERSION' works in all 3 of those. The existence of shell variables
that don't show up in the output of 'set' was something I would never have
guessed.
And I'm still a little shocked that $SHELL is not as magical as I always
assumed it was. I've been thinking of it as a special "identify yourself"
query, basically equivalent to $(realpath /proc/$$/exe) but without the
dependency on Linux-style /proc or realpath(1). Based on what it actually
does, it should have been called $LOGINSHELL.
At least if anyone cares about that printf thing they've got some version
strings to look at.
Hold on... breaking news... I figured something out.
$ echo ${.sh.version}
Version M 93s+ 2008-01-31
$ printf '%d\n' aaa
0
$ aaa=111
$ printf '%d\n' aaa
111
$ bbb=222
$ printf '%d\n' aaa+bbb
333
$
So it's parsed as an arithmetic expression. Undocumented feature? I find it
documented in zshbuiltins(1) under printf:
With the numeric format specifiers, if the corresponding
argument starts with a quote character, the numeric value of the
following character is used as the number to print otherwise the
argument is evaluated as an arithmetic expression.
but I see no corresponding explanation in ksh(1).
In zsh, this behavior can be avoided by calling "command printf" to force the
external command to be executed. In ksh, "command" doesn't work that way
apparently (leaving me confused again since I thought that avoiding builtins
was the only reason for "command" to exist).
--
Alan Curry
Janis Papanagnou
See http://www2.research.att.com/sw/download/man/man1/ksh.html
"Variables can be referenced by name within an arithmetic
expression without using the parameter expansion syntax."
For the whole context see below...
Arithmetic Evaluation
The shell performs arithmetic evaluation for arithmetic substitution,
to evaluate an arithmetic command, to evaluate an indexed array
subscript, and to evaluate arguments to the built-in commands shift
and let. Evaluations are performed using double precision floating
point arithmetic or long double precision floating point for systems
that provide this data type. Floating point constants follow the
ANSI-C programming language floating point conventions. Integer
constants follow the ANSI-C programming language integer constant
conventions although only single byte character constants are
recognized and character casts are not recognized. In addition
constants can be of the form [ base# ]n where base is a decimal
number between two and sixty-four representing the arithmetic base and
n is a number in that base. The digits above 9 are represented by
the lower case letters, the upper case letters, @, and _ respectively.
For bases less than or equal to 36, upper and lower case characters
can be used interchangeably.
An arithmetic expression uses the same syntax, precedence, and
associativity of expression as the C language. All the C language
operators that apply to floating point quantities can be used. In
addition, the operator ** can be used for exponentiation. It has
higher precedence than multiplication and is left associative. In
addition, when the value of an arithmetic variable or sub-expression
can be represented as a long integer, all C language integer
arithmetic operations can be performed. Variables can be referenced by
name within an arithmetic expression without using the parameter
expansion syntax. When a variable is referenced, its value is
evaluated as an arithmetic expression.
Janis
Seebs
> But the latest release is not called "gcc99-2010". That would be stupid.
It does seem a bit weird. The real "version" is the "s". 93s is the version
after 93r. The 2008 is a red herring, I think.
> zsh has $ZSH_VERSION; bash has $BASH_VERSION; even posh has $POSH_VERSION;
> 'set|grep VERSION' works in all 3 of those. The existence of shell variables
> that don't show up in the output of 'set' was something I would never have
> guessed.
Yeah. :)
> So it's parsed as an arithmetic expression. Undocumented feature?
Probably!
Greg Andrews
>
>Anyway I was just trying to say look, here's a ksh that reproduces the bug in
>the original report, and finding its version string was harder than expected.
>I thought my post would possibly be helpful despite being incomplete.
>
>zsh has $ZSH_VERSION; bash has $BASH_VERSION; even posh has $POSH_VERSION;
>'set|grep VERSION' works in all 3 of those. The existence of shell variables
>that don't show up in the output of 'set' was something I would never have
>guessed.
>
You've obviously never used a csh variant, where the 'set' and 'env'
commands usually show different sets of variables.
Consider the possibility that ksh pre-dates bash, zsh and posh, and ksh's
approach to reporting its version number was not imitated by the shells
that were written later.
See the dates in the top 3 rows of the table here:
http://en.wikipedia.org/wiki/Comparison_of_computer_shells
>
>And I'm still a little shocked that $SHELL is not as magical as I always
>assumed it was. I've been thinking of it as a special "identify yourself"
>query, basically equivalent to $(realpath /proc/$$/exe) but without the
>dependency on Linux-style /proc or realpath(1). Based on what it actually
>does, it should have been called $LOGINSHELL.
>
Consider the possibility that when a major Unix shell that's been in use
for many, many years doesn't behave the way you expect....there might be
a reason for it. That reason may be obscured a little by the mists of
history, but it's there. Backward compatibility with the Bourne shell
so existing scripts wouldn't crash, comes to mind as a possibility.
-Greg
--
::::::::::::: Greg Andrews ::::: ge...@panix.com :::::::::::::
I have a map of the United States that's actual size.
-- Steven Wright
Alan Curry
Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>
>See http://www2.research.att.com/sw/download/man/man1/ksh.html
>
> "Variables can be referenced by name within an arithmetic
> expression without using the parameter expansion syntax."
Nothing in that sentence says that arguments to printf may be considered
arithmetic expressions. Note that /usr/bin/printf %d 1+1 does not print 2
so it's not just a matter of whether shell variables are available or not.
>
>For the whole context see below...
>
> Arithmetic Evaluation
> The shell performs arithmetic evaluation for arithmetic substitution,
> to evaluate an arithmetic command, to evaluate an indexed array
> subscript, and to evaluate arguments to the built-in commands shift
> and let.
A nice compact list of places where arithmetic expressions can be found. And
it doesn't include printf.
--
Alan Curry
Alan Curry
Greg Andrews <ge...@panix.com> wrote:
>pac...@kosh.dhis.org (Alan Curry) writes:
>>
>>zsh has $ZSH_VERSION; bash has $BASH_VERSION; even posh has $POSH_VERSION;
>>'set|grep VERSION' works in all 3 of those. The existence of shell variables
>>that don't show up in the output of 'set' was something I would never have
>>guessed.
>>
>
>You've obviously never used a csh variant, where the 'set' and 'env'
>commands usually show different sets of variables.
${.sh.version} isn't an environment variable though... it's shown by neither
'set' nor 'env'.
>
>Consider the possibility that ksh pre-dates bash, zsh and posh, and ksh's
>approach to reporting its version number was not imitated by the shells
>that were written later.
I've only known about the ksh approach for a few hours, so maybe it hasn't
really sunk in yet, but so far I don't think the ksh approach is worthy of
imitating. A variable that's so special you can't find it with set|grep, and
why the hell does it have dots in it, adding the burden of typing braces
around it when you want to expand it? $ZSH_VERSION is cleaner.
>>
>>And I'm still a little shocked that $SHELL is not as magical as I always
>>assumed it was. I've been thinking of it as a special "identify yourself"
>>query, basically equivalent to $(realpath /proc/$$/exe) but without the
>>dependency on Linux-style /proc or realpath(1). Based on what it actually
>>does, it should have been called $LOGINSHELL.
>>
>
>Consider the possibility that when a major Unix shell that's been in use
>for many, many years doesn't behave the way you expect....there might be
>a reason for it. That reason may be obscured a little by the mists of
>history, but it's there. Backward compatibility with the Bourne shell
>so existing scripts wouldn't crash, comes to mind as a possibility.
Yes, I'm sure it made sense at the time, somehow. The above was just a
comment about how easy it is to make wrong assumptions about things you've
never actually tried. I would have thought that exec $SHELL "$0" was the way
for a script to reload itself using the same shell currently running it,
which would be a good enough explanation for why $SHELL exists.
The final question for the thread should be: is it POSIX-compliant for
printf %d 1+1 to print 2?
--
Alan Curry
Greg Andrews
>In article <icad54$m4$1...@reader1.panix.com>,
>Greg Andrews <ge...@panix.com> wrote:
>>pac...@kosh.dhis.org (Alan Curry) writes:
>>>
>>>zsh has $ZSH_VERSION; bash has $BASH_VERSION; even posh has $POSH_VERSION;
>>>'set|grep VERSION' works in all 3 of those. The existence of shell variables
>>>that don't show up in the output of 'set' was something I would never have
>>>guessed.
>>>
>>
>>You've obviously never used a csh variant, where the 'set' and 'env'
>>commands usually show different sets of variables.
>
>${.sh.version} isn't an environment variable though... it's shown by neither
>'set' nor 'env'.
>
Who's talking about environment variables? You said "shell variables", not
"environment variables", and I used the very same term. I was talking about
your amazement that the 'set' command would not show all shell variables
when shells have done that for 25+ years.
>>
>>Consider the possibility that ksh pre-dates bash, zsh and posh, and ksh's
>>approach to reporting its version number was not imitated by the shells
>>that were written later.
>
>I've only known about the ksh approach for a few hours, so maybe it hasn't
>really sunk in yet, but so far I don't think the ksh approach is worthy of
>imitating. A variable that's so special you can't find it with set|grep, and
>why the hell does it have dots in it, adding the burden of typing braces
>around it when you want to expand it? $ZSH_VERSION is cleaner.
>
I wasn't really talking about matters of preference. I was talking about
documentation. When I do a google search for the phrase "ksh version"
the first result described the interactive methods, and the second result
had "Starting with ksh93, you can use ${.sh.version} to see which ksh
version you are using."
I happened to have bought the Bolsky/Korn book several years ago when I
began writing ksh scripts, so I'm familiar with the ${.sh.*} namespace.
My point is the documentation is there. You might not like where ksh93
keeps its version number, but there's not really any secret about it.
You just need to question your assumptions that all shells are the same.
(of course they aren't: why would someone bother to write a mere clone?)
>
>The final question for the thread should be: is it POSIX-compliant for
>printf %d 1+1 to print 2?
>
It's my bet that compliance isn't an issue because POSIX never defined
the behavior of printf (or alternatively the exclusive list of where
arithmetic evaluation should be performed). I could be mistaken, though.
Try this variant of your example:
$ aaa=555
$ bbb=123
$ printf '%s\n%d\n' aaa+bbb aaa+bbb
aaa+bbb
678
So ksh93 applies arithmetic evaluation to the printf arguments *when you
ask it to* by using an arithmetic format specifier.
That isn't what I would have expected, but I'm not going to say it's wrong.
If you're coding for different shells, you're going to run into many kinds
of differences. What can you do but get used to it?
Janis Papanagnou
That is correct. The shift statement is also not listed, and probably many
more built-in commands as well. To get the picture you must probably read
the whole document and understand the philosophy behind the ksh93 language,
and know where there are to expect arithmetic expressions. IMO it makes
sense to just speak in terms of language "arithmetic experssions" than to
repeat for every single command and built-in construct that there may be
such expressions. It's primarily not a printf issue, but a shell language
design issue.
Use of non-dereferenced variable names had been there in a few places for
a long time, but in the recent versions most (all?) "arithmetic places" have
been "fixed" to allow undereferenced expressions. It seems that the shell
authors wanted to get rid of the '$' in places where that is - determined
by context - unnecessary, probably to make the code better legible.
Janis
Alan Curry
Greg Andrews <ge...@panix.com> wrote:
>pac...@kosh.dhis.org (Alan Curry) writes:
>>In article <icad54$m4$1...@reader1.panix.com>,
>>Greg Andrews <ge...@panix.com> wrote:
>>>pac...@kosh.dhis.org (Alan Curry) writes:
>>>>
>>>>zsh has $ZSH_VERSION; bash has $BASH_VERSION; even posh has $POSH_VERSION;
>>>>'set|grep VERSION' works in all 3 of those. The existence of shell variables
>>>>that don't show up in the output of 'set' was something I would never have
>>>>guessed.
>>>>
>>>
>>>You've obviously never used a csh variant, where the 'set' and 'env'
>>>commands usually show different sets of variables.
>>
>>${.sh.version} isn't an environment variable though... it's shown by neither
>>'set' nor 'env'.
>>
>
>Who's talking about environment variables? You said "shell variables", not
>"environment variables", and I used the very same term. I was talking about
>your amazement that the 'set' command would not show all shell variables
>when shells have done that for 25+ years.
You're the one who mentioned "env", therefore you were the first one to start
talking about environment variables where I had been talking about shell
variables. The evidence is above, in the material you quoted right before
this weird question. What other shell besides ksh has shell variables that
don't show up in the "set" list?
>
>I wasn't really talking about matters of preference. I was talking about
>documentation. When I do a google search for the phrase "ksh version"
>the first result described the interactive methods, and the second result
>had "Starting with ksh93, you can use ${.sh.version} to see which ksh
>version you are using."
My initial contribution, which has got me into so much trouble, was made
simply to answer the question "what shell version doesn't give an error in
response to printf %d aaa", which at that point was being considered as a bug
because nobody involved in the thread had yet figured out that it was a
feature. I tried all the shells within reach, and found one that had the
"bug" so I answered the question that had been asked.
The version given by dpkg -l ksh was (I still believe) a sufficient answer.
The other stuff, in which I'd tried and failed to find a shell variable
containing a version number, was included for its humor value. And the fact
that the "93" refuses to disappear from the version number after 17 years is
legitimately funny to me.
I've read many shell man pages, including the Bourne shell, csh, tcsh, ash,
and zsh, but never ksh. Since I was only reporting the existence of a shell
which reproduced the behavior in the original post, it didn't seem necessary
that I should study that shell.
>>
>>The final question for the thread should be: is it POSIX-compliant for
>>printf %d 1+1 to print 2?
>>
>
>It's my bet that compliance isn't an issue because POSIX never defined
>the behavior of printf (or alternatively the exclusive list of where
>arithmetic evaluation should be performed). I could be mistaken, though.
People recommend printf as a replacement for echo, because it's POSIXly
guaranteed not to have a problem with stuff like echo -n vs. echo \c but
all you need for that is %s. Still, I don't see anything in
http://www.opengroup.org/onlinepubs/009695399/utilities/printf.html
that would allow ksh's behavior.
But then I don't have the "feel" of ksh, so I don't know whether it cares
that its cool features aren't POSIX-compliant. zsh certainly doesn't.
--
Alan Curry
Alexvai
By the way i am using ksh:
$ echo $0
-ksh
$ echo ${.sh.version}
Version JM 93t+ 2010-02-14
$
My original target was to check if the input is integer number and i
did it like that : :)
echo ${NUMBER_TO_TEST} | egrep -q "^[-+]?([1-9][0-9]*|0)$"
if [[ $? -eq 0 ]] then
return ${__EXIT_STATUS_SUCCESS}
else
return ${__EXIT_STATUS_FAILED}
fi
Bill Marcum
>>>${.sh.version} isn't an environment variable though... it's shown by neither
>>>'set' nor 'env'.
>>>
>>
>>Who's talking about environment variables? You said "shell variables", not
>>"environment variables", and I used the very same term. I was talking about
>>your amazement that the 'set' command would not show all shell variables
>>when shells have done that for 25+ years.
>
> You're the one who mentioned "env", therefore you were the first one to start
> talking about environment variables where I had been talking about shell
> variables. The evidence is above, in the material you quoted right before
> this weird question. What other shell besides ksh has shell variables that
> don't show up in the "set" list?
>
nor a shell variable, although it is written like one. It's just a
feature of ksh. Maybe the ksh developers were following the example of
the Unix file system, where filenames beginning with "." are "hidden".
Does ksh have a set option equivalent to "ls -a"?
Seebs
> really sunk in yet, but so far I don't think the ksh approach is worthy of
> imitating. A variable that's so special you can't find it with set|grep, and
> why the hell does it have dots in it, adding the burden of typing braces
> around it when you want to expand it? $ZSH_VERSION is cleaner.
Namespace pollution.
Janis Papanagnou
>
>>[...]
> You could say that ${.sh.version} is neither an environment variable
> nor a shell variable, although it is written like one. It's just a
> feature of ksh. Maybe the ksh developers were following the example of
> the Unix file system, where filenames beginning with "." are "hidden".
I see the dot as a common separator like in hierarchical schemas like ISO
OIDs, or language data structure "navigation" (Pascal records, C structs),
and the leading dot identifies the start of a root namespace. The variables
in the shell's namespace variables are identified by a leading /.sh./.
There's a paragraph about Name Spaces and the namespace command in the ksh
man page.
Janis
> [...]
Janis Papanagnou
>
> By the way i am using ksh:
>
> $ echo $0
> -ksh
> $ echo ${.sh.version}
> Version JM 93t+ 2010-02-14
> $
>
>
> My original target was to check if the input is integer number and i
> did it like that : :)
The usual standard conformant suggestion is to use a case statement.
But since you use ksh why not using ksh regular expressions than rely
on external command...
if [[ ${NUMBER_TO_TEST} == ?(+|-)+([0-9]) ]]
then
printf "(optionally signed) integral number\n"
else
printf "non-(optionally signed) integral number\n"
fi
(Just an example; you may want to tweak the regular expression and
disallow "000" as a valid number as in your regexp.)
Janis
Alexvai
wrote:
>
> - Show quoted text -
I am not familiar with this kind of ksh regular expressions, where can
read a full info about ?
Janis Papanagnou
In the ksh man page. Also online available, for ksh93 e.g. at
http://www2.research.att.com/sw/download/man/man1/ksh.html
Janis