I thought about typeset -u :
typeset -u MYVARIABLE=$lowercasevar
but under linux, typeset does not support -u !
Any ideas ?
# echo "$VAR" | tr 'a-z' 'A-Z'
works at least under AIX
HTH
Hajo
Linux is a kernel, not a shell. bash is a shell, which does not provide
typeset (aka declare) -u. ksh is a shell, which does.
--
Kevin Rodgers
"typeset -u" is peculiar to ksh; it's a feature of the shell you
are using, not Linux or any other OS.
Most, if not all, Linux distributions come with pdksh (which may be
named ksh), and KornShell93 is available from
<http://www.kornshell.com>.
The portable way to convert to uppercase is to use tr:
echo $string | tr '[a-z]' '[A-Z]'
--
Chris F.A. Johnson http://cfaj.freeshell.org
===================================================================
My code (if any) in this post is copyright 2003, Chris F.A. Johnson
and may be copied under the terms of the GNU General Public License
Haven't checked in a while. Do they still have that silly packaging scheme?
I couldn't make head nor tail of it...
> The portable way to convert to uppercase is to use tr:
>
>echo $string | tr '[a-z]' '[A-Z]'
Hmmm...
$ string="HELLO"
$ echo $string | tr '[a-z]' '[A-Z]'
HELLO
$ uname
SunOS
$
I guess there portable and there's portable...
gawk -v "string=$string" 'BEGIN {print tolower(string)}'
>In article <bgeg4g$m9039$1...@ID-136730.news.uni-berlin.de>,
>Chris F.A. Johnson <c.f.a....@rogers.com> wrote:
>>On Fri, 01 Aug 2003 at 14:58 GMT, Eric Rave wrote:
>>> I want to convert string in uppercase...
>>>
>>> I thought about typeset -u :
>>> typeset -u MYVARIABLE=$lowercasevar
>>>
>>> but under linux, typeset does not support -u !
>>> Any ideas ?
>>
>> "typeset -u" is peculiar to ksh; it's a feature of the shell you
>> are using, not Linux or any other OS.
>>
>> Most, if not all, Linux distributions come with pdksh (which may be
>> named ksh), and KornShell93 is available from
>> <http://www.kornshell.com>.
>
>Haven't checked in a while. Do they still have that silly packaging scheme?
>I couldn't make head nor tail of it...
>
>> The portable way to convert to uppercase is to use tr:
>>
>>echo $string | tr '[a-z]' '[A-Z]'
>
>Hmmm...
>
>$ string="HELLO"
You want string="hello", as the tr command is being used to convert
lower to uppercase.
>$ echo $string | tr '[a-z]' '[A-Z]'
>HELLO
>$ uname
>SunOS
>$
>
>I guess there portable and there's portable...
>
>gawk -v "string=$string" 'BEGIN {print tolower(string)}'
Don't know if all variants of tr have the lower and upper options, but
my SCO OSR5 and AIX 4.3 systems allow
# string="hello"
# echo $string | tr "[:lower:]" "[:upper:]"
HELLO
#
Scott McMillan
What's wrong with "HELLO"? Do you have a different definition of
uppercase?
> gawk -v "string=$string" 'BEGIN {print tolower(string)}'
Gawk is not universally installed.
$ uname
SunOS
$ gawk -v "string=$string" 'BEGIN {print tolower(string)}'
-bash: gawk: command not found
$ awk -v "string=$string" 'BEGIN {print tolower(string)}'
awk: syntax error near line 1
awk: bailing out near line 1
$ nawk -v "string=$string" 'BEGIN {print tolower(string)}'
nawk: unknown option: -v.
Usage: nawk [-f source] [-Fc] ['cmds'] [variable=value ...] [file ...]
source line number 1
context is
Oops - you're right. Using "hello" as input gets "HELLO" as output. ISTR
that there is some ambiguity among versions of tr, etc as to whether or not
you need the square brackets, but I don't seem to have the details at hand.
>> gawk -v "string=$string" 'BEGIN {print tolower(string)}'
>
> Gawk is not universally installed.
Obvious, it should be. The point is that the gawk command will either work
(if it is installed on your system - and if it isn't, your system is
defective) or give an unmistakable (Command not found) error message. What
is of more concern is the ambiguities in some of the commands - and as
I said, I'm not sure that tr is as universal and unchanging as you seem to
think it is.
Who cares? The square-bracket syntax always works. Why bother
about using non-portable methods to do things than can be done
portably?
There's an advantage to using the newer classes, [:upper:]
and [:lower:] only if you are using a localized character set.
>>> gawk -v "string=$string" 'BEGIN {print tolower(string)}'
>>
>> Gawk is not universally installed.
>
> Obvious, it should be.
Why use a large utility to do the work of a small one?
> The point is that the gawk command will either work (if it is
> installed on your system - and if it isn't, your system is
> defective) or give an unmistakable (Command not found) error
> message. What is of more concern is the ambiguities in some of the
> commands - and as I said, I'm not sure that tr is as universal and
> unchanging as you seem to think it is.
A system without tr is defective; one without gawk is not.
Sorry, no, not even that.
I happened to come across a system, where a German collating sequence
was preconfigured, and [a-z] and [A-Z] did NOT expand to what we
would expect, since lower and upper case characters where mixed (in both).
The effect was somewhat crazy.
We ended up with using
tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ
for portable scripts, or at least setting LC_COLLATE="" .
There are other pitfalls with LC_COLLATE, e.g. the implicit sorting
of "ls" changes. Has bitten me, too.
--
Heiner Marxen hei...@insel.de http://www.drb.insel.de/~heiner/
> I happened to come across a system, where a German collating
> sequence was preconfigured, and [a-z] and [A-Z] did NOT expand to
> what we would expect, since lower and upper case characters where
> mixed (in both)
...
> We ended up with using
>
> tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ
>
> for portable scripts, or at least setting LC_COLLATE="" .
So that tr doesn't understand '[:upper:]' & '[:lower:]'?
- parv
--
In order to reach me, do away w/ WhereElse in the address.
A programmer, budding Unix system administrator, and amateur photographer
seeks employment: http://www103.pair.com/parv/work/
I vaguely recall that some ancient versions of tr require
echo hello | tr '[a-z]' '[A-Z]'
rather than
echo hello | tr 'a-z' 'A-Z'
My SunOS 4.1.3 system (circa 1992) doesn't require the brackets, and
the examples in Kernighan & Pike's _The UNIX Programming Environment_,
published in 1984, show
tr a-z A-Z
and
tr A-Z a-z
so it's probably safe to assume that the brackets aren't required on
any existing system.
Of course, the brackets are harmless if you include them; they just
specify that the '[' and ']' characters are mapped to themselves.
This all assumes that the current locale is sufficiently well-behaved.
You can also use
echo hello | dd conv=ucase 2>/dev/null
(you need to redirect stderr to get rid of the status messages). The
GNU (coreutils 5.0) dd program uses C's toupper(), so it should pay
attention to the current locale.
--
Keith Thompson (The_Other_Keith) k...@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
I just found some ancient Unix man pages at
<http://minnie.tuhs.org/UnixTree/>. If I'm interpreting the escape
sequences correctly (the man macros have changed over the years), the
"tr.1" man page for Sixth Edition Unix, released in May 1975, shows
the "[a-z]" syntax, and the "tr.1" man page in Seventh Edition Unix,
released in January 1979, shows "a-z". (Third Edition, February 1973,
didn't have the "tr" command; it first appeared in Fourth Edition,
November 1973.)
Unless there's some existing Unix-like system whose ancestry branched
off the Bell Labs code before 1979, I don't think the brackets are
necessary.
BTW, there *are* still existing versions of tr that don't support
"[:upper:]" and "[:lower:]". Even on Solaris 9, I get:
% echo hello | /usr/ucb/tr '[:lower:]' '[:upper:]'
heuup
though /usr/bin/tr prints "HELLO".
> the "tr.1" man page for Sixth Edition Unix, released in May 1975,
> shows the "[a-z]" syntax, and the "tr.1" man page in Seventh Edition
> Unix, released in January 1979, shows "a-z". [...]
> Unless there's some existing Unix-like system whose ancestry branched
> off the Bell Labs code before 1979, I don't think the brackets are
> necessary.
I'm not sure about the specific history of 'tr', but, to quote POSIX
1992 Rationale:
"On historical System V systems, a range expression requires enclosing
square-brackets"
and many commercial unixes are derived from System V.
Wikipedia says that " AT&T combined various versions developed at
other universities and companies into Unix System V Release 1",
so perhaps they picked tr syntax from something based on the 6th
edition.
I don't know of any system that could be called even almost current
that'd require the brackets, though.
--
Tapani Tarvainen