internal alias

I'm accustomed to using ksh93 and have a number of scripts written for
that interpreter. I have to convert them to bash. And I find mostly
thery are compatable but for the echo/print difference.

I've grown to prefer `print' so that is scattered all over these
scripts.

Looking for a lazy way out:

I didn't notice anything in the manual to help me see how or if it can
be done.

I wondered if there is some mechanism in bash where inside a script I
could alias `print' to `echo' instead of having to actually change
them all.

It would be much simpler to just put something at the top of each
script that makes bash see `echo' where it says `print' and see
if the script will run ok otherwise.

Re: internal alias

On Mon, 07 Jan 2008 18:43:13 -0600, reader wrote:

> I'm accustomed to using ksh93 and have a number of scripts written for
> that interpreter. I have to convert them to bash. And I find mostly
> thery are compatable but for the echo/print difference.
>
> I've grown to prefer `print' so that is scattered all over these
> scripts.
>
> Looking for a lazy way out:
>
> I didn't notice anything in the manual to help me see how or if it can
> be done.
>
> I wondered if there is some mechanism in bash where inside a script I
> could alias `print' to `echo' instead of having to actually change them
> all.
>
> It would be much simpler to just put something at the top of each script
> that makes bash see `echo' where it says `print' and see if the script
> will run ok otherwise.

Add a function called "print", e.g.

print(){ echo "$@" ;}

Re: internal alias

On Jan 7, 4:43=A0pm, rea...@newsguy.com wrote:
> I'm accustomed to using ksh93 and have a number of scripts written for
> that interpreter. =A0 I have to convert them to bash. =A0And I find mostly=

> thery are compatable but for the echo/print difference.

Too bad. Despite some opinions to the contrary, ksh(1) version
1993 is in design and execution a superior shell to bash(1).

> I've grown to prefer `print' so that is scattered all over these
> scripts.

Keep in mind that that options acceptable to "echo" (builtin
_and_ external versions!) are a small subset of the capabilities
of ksh(1) print and printf.

> Looking for a lazy way out:

The previous reply is sufficient, but you still might gain some
advantage from automated conversion utitilies, if your host OS
is commensurate. See my past post at:

http://groups.google.com/group/comp.unix.shell/browse_thread /thread/82557352=
266bc450/51ed6773be861c72?lnk=3Dst&q=3D#51ed6773be861c72

=3DBrian

Re: internal alias

Icarus Sparry writes:

>> It would be much simpler to just put something at the top of each script
>> that makes bash see `echo' where it says `print' and see if the script
>> will run ok otherwise.
>
> Add a function called "print", e.g.
>
> print(){ echo "$@" ;}

Now that is pretty slick... I wouldn't have thought of it in a dozen
years. I'd like to think I'd have thought after while but naa.. I
wouldn't have.

In this case I guess it is fortunate that my scripts are primitive. I
think I can just change `echo' to `echo -e' for the occasions where my
print calls involve newlines all of them will just work.

You saved me from breaking a dedication to laziness since I retired a
few years ago.

Re: internal alias

bsh writes:

>> I'm accustomed to using ksh93 and have a number of scripts written for
>> that interpreter.   I have to convert them to bash.  And I find mostly
>> thery are compatable but for the echo/print difference.
>
> Too bad. Despite some opinions to the contrary, ksh(1) version
> 1993 is in design and execution a superior shell to bash(1).
>

It will probably start a religious war but I'm kind of curious what
you have in mind. I suspect it will be pretty much outside of my
usage though since my skill are pretty low level.

I liked ksh93 for the regex matching.. like having awk in your shell
script without calling it. I did not realize that bash now possesses
that skill too ... the =~ operator.

Not sure when that happened but I think its kind of new. I have'nt
really used bash for a good while, except for actual shell. All shell
scripting was in ksh.

I'm starting to think I might be smarter to just go with bash. At my
usage level its very close.

Re: internal alias

On Thu, 10 Jan 2008 00:00:47 -0600, reader wrote:

> bsh writes:
>
>>> I'm accustomed to using ksh93 and have a number of scripts written for
>>> that interpreter.   I have to convert them to bash.  And I find mostly
>>> thery are compatable but for the echo/print difference.
>>
>> Too bad. Despite some opinions to the contrary, ksh(1) version 1993 is
>> in design and execution a superior shell to bash(1).
>>
>>
> It will probably start a religious war but I'm kind of curious what you
> have in mind. I suspect it will be pretty much outside of my usage
> though since my skill are pretty low level.
>
> I liked ksh93 for the regex matching.. like having awk in your shell
> script without calling it. I did not realize that bash now possesses
> that skill too ... the =~ operator.

There are things that awk & ksh (& perl & tcl & python & lua & ...) have
but bash does not such as associative arrays. For trivial sizes you can
simulate them with a linear search and a pair of arrays, but this soon
gets slow. So then you start programing some kind of balanced heap. Soon
your quick little script starts to run to thousands of lines and people
start asking why you didn't program it in awk/perl/python/whatever.

Then there are floating point numbers.

Then you can load commands into ksh93 to avoid lots of the overhead. True
you can add extensions to bash, but then you may hit licensing issues (no
one seems very sure if you dynamicaly load code into bash if you have to
make it available under the GPL - the concensus at work is "yes")

Then there is the better option parser, complete with the ability to
generate man pages.
> Not sure when that happened but I think its kind of new. I have'nt
> really used bash for a good while, except for actual shell. All shell
> scripting was in ksh.
>
> I'm starting to think I might be smarter to just go with bash. At my
> usage level its very close.

If you have a choice, I would stick with ksh93.

Re: internal alias

On 2008-01-08, Icarus Sparry wrote:
>
> print(){ echo "$@" ;}

Better would be:

print()
{
printf "%b\n" "$*"
}

Even better would be to add handling for print's options.

Or, if you are using bash, there is a dynamically loadable version
of print that comes with the source code.

--
Chris F.A. Johnson, author
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
===== My code in this post, if any, assumes the POSIX locale
===== and is released under the GNU General Public Licence

Re: internal alias

Icarus Sparry writes:

>> It will probably start a religious war but I'm kind of curious what you
>> have in mind. I suspect it will be pretty much outside of my usage
>> though since my skill are pretty low level.
>>
>> I liked ksh93 for the regex matching.. like having awk in your shell
>> script without calling it. I did not realize that bash now possesses
>> that skill too ... the =~ operator.
>
> There are things that awk & ksh (& perl & tcl & python & lua & ...) have
> but bash does not such as associative arrays.

That sounds useful. Can you give an example of associative array
usage in ksh?

I forgot the main reason I liked ksh over bash and that is how easy it is
to generate a regular array with `set -A'.

Someone may know how to do that as easily in bash but it has escaped
me.

[...]

>> I'm starting to think I might be smarter to just go with bash. At my
>> usage level its very close.
>
> If you have a choice, I would stick with ksh93.

Just thinking out loud here:
The things you've mentioned are things I've never touched in ksh and
as you point out, at the point where things like that become needed,
its time for perl or python etc.

Re: internal alias

On Thu, 10 Jan 2008 11:16:01 -0600, reader wrote:

> Icarus Sparry writes:
>
>>> It will probably start a religious war but I'm kind of curious what
>>> you have in mind. I suspect it will be pretty much outside of my
>>> usage though since my skill are pretty low level.
>>>
>>> I liked ksh93 for the regex matching.. like having awk in your shell
>>> script without calling it. I did not realize that bash now possesses
>>> that skill too ... the =~ operator.
>>
>> There are things that awk & ksh (& perl & tcl & python & lua & ...)
>> have but bash does not such as associative arrays.
>
> That sounds useful. Can you give an example of associative array usage
> in ksh?
>
> I forgot the main reason I liked ksh over bash and that is how easy it
> is to generate a regular array with `set -A'.

typeset -A wives
wives["fred"]="wilma"
wives["barny"]="betty"

while read husband
do
case "${wives[$husband]}" in
"") echo Single;;
*) echo "Married to ${wives[$husband]}" ;;
esac
done


> Someone may know how to do that as easily in bash but it has escaped me.

declare -a xx
xx=(1 2 3)

>>> I'm starting to think I might be smarter to just go with bash. At my
>>> usage level its very close.
>>
>> If you have a choice, I would stick with ksh93.
>
> Just thinking out loud here:
> The things you've mentioned are things I've never touched in ksh and as
> you point out, at the point where things like that become needed, its
> time for perl or python etc.

The assertion is that modern ksh has everything in it that you need from
perl, so you don't need two languages on the system/in your mind. You may
or may not find this assertion convincing.

Re: internal alias

Icarus Sparry writes:

> typeset -A wives
> wives["fred"]="wilma"
> wives["barny"]="betty"

Thats pretty slick... do you know if something similar can be done in
bash? Slogging through man bash...I haven't been able to tell.

Re: internal alias

reader@newsguy.com writes:

> Icarus Sparry writes:
>
>> typeset -A wives
>> wives["fred"]="wilma"
>> wives["barny"]="betty"
>
> Thats pretty slick... do you know if something similar can be done in
> bash? Slogging through man bash...I haven't been able to tell.

Please diregard... that was pretty lame since you already supplied the
syntax.

declare -a wives
wives["fred"]="wilma"
wives["barny"]="betty"

Re: internal alias

On Fri, 11 Jan 2008 13:37:15 -0600, reader@newsguy.com wrote:
> Icarus Sparry writes:
>
>> typeset -A wives
>> wives["fred"]="wilma"
>> wives["barny"]="betty"
>
> Thats pretty slick... do you know if something similar can be done in
> bash? Slogging through man bash...I haven't been able to tell.

wives_fred=wilma
wives_barny=betty

awk '
BEGIN {
wives["fred"] = "wilma"
wives["barny"] = "betty"
...
}'

all work in bash.

--
Stephane

Re: internal alias

Icarus Sparry writes:

>> I forgot the main reason I liked ksh over bash and that is how easy it
>> is to generate a regular array with `set -A'.
>
> typeset -A wives
> wives["fred"]="wilma"
> wives["barny"]="betty"
>
> while read husband
> do
> case "${wives[$husband]}" in
> "") echo Single;;
> *) echo "Married to ${wives[$husband]}" ;;
> esac
> done
>
>
>> Someone may know how to do that as easily in bash but it has escaped me.
>
> declare -a xx
> xx=(1 2 3)

Sorry.. still pestering about this.

Is there an equivalent way to assign an array (not necessarily
associative) in bash, that is similar to ksh `set -A array cmd'

in ksh93:
set -A inls *
cnt=0
for ii in ${inls[@]};do
echo "inls[$cnt] is $ii"
cnt=$((cnt + 1))
done

(I know a simple for loop in either ksh or bash
for ii in `ls`
can do this, but interested here in array syntax)

Can `declare' (or something else) in bash be made to do something like
that? I'm not getting the syntax from `man bash'.

Re: internal alias

reader@newsguy.com wrote:
>
> in ksh93:
> set -A inls *
> cnt=0
> for ii in ${inls[@]};do
> echo "inls[$cnt] is $ii"
> cnt=$((cnt + 1))
> done
>
> Can `declare' (or something else) in bash be made to do something like
> that? I'm not getting the syntax from `man bash'.
>
inls=(*)
cnt=0
for i in "${inls[@]}" ;do
echo "${inls[cnt]}"
cnt=$((cnt+1))
done

don't forget the quote around "${inls[@]}" or the array elements will
be word splitted on space bash doesn't have associative arrays.

(on another not use for f in *;do ...rather than for f in `ls`;do...
--
pgas @ SDF Public Access UNIX System - http://sdf.lonestar.org

Re: internal alias

On Sat, 12 Jan 2008 05:03:34 +0000 (UTC), pgas wrote:
> reader@newsguy.com wrote:
>>
>> in ksh93:
>> set -A inls *
>> cnt=0
>> for ii in ${inls[@]};do
>> echo "inls[$cnt] is $ii"
>> cnt=$((cnt + 1))
>> done
>>
>> Can `declare' (or something else) in bash be made to do something like
>> that? I'm not getting the syntax from `man bash'.
>>
> inls=(*)
> cnt=0
> for i in "${inls[@]}" ;do
> echo "${inls[cnt]}"
> cnt=$((cnt+1))
> done
[...]

In zsh:

inls=(*(N))

the (N) globbing qualifier is so that if there's no file, it
expands to the empty list.

Also, in zsh, contrary to ksh and bash, arrays are a separate
type from scalars (in ksh and bash, $scalar is ${scalar[0]}), so
that you can do:

for i in $inls; do
printf '%s\n' $inls[cnt++]
done

Which you can also write:

for i ($inls) print -rl -- $i

Note that $inls expands to the list of non-empty elements of the
$inls, which is fine in this case as $inls won't contain any
empty element. But if you want to include empty elements, it's
the same syntax as in ksh/bash "${inls[@]}" (which you can
shorten to "$inls[@]".

Also note that contrary to bash and ksh, zsh's arrays are really
arrays (and start at 0 to be consistent with $@ which is
implemented as an array). So that a[3] = 1 creates an array of 3
elements, the first 2 ones being empty.

ksh and bash arrays are sort of associative arrays where the
keys are limited to integers only. Until recently there was not
way to retrieve the list of keys of an array. It also means it
is very difficult to copy an array.

In zsh:

b=("$a[@]")

In ksh93, bash:

b=()
for i in "${a[@]}"; do
b[i]=${a[i]}
done

In ksh88/pdksh, older bash: impossible.

--
Stephane

Re: internal alias

wrote:
> bsh writes:
> > > ...

> It will probably start a religious war but I'm kind of curious what
> you have in mind. I suspect it will be pretty much outside of my
> usage though since my skill are pretty low level.

You're asking my opinion? Oh, bad, bad idea! ;)

> Not sure when that happened but I think its kind of new. I haven't
> really used bash for a good while, except for actual shell. All shell
> scripting was in ksh.
> I liked ksh93 for the regex matching.. like having awk in your shell
> script without calling it. I did not realize that bash now possesses
> that skill too ... the =~ operator.

Oh, you have no idea! Expanded Regular Expressions *slash* Globbing
syntax has been quite enhanced since its inception in ksh88.

For instance (and I know that at your usage level you will probably
not even need to use it):

$ var=${var#~(E).*[[:space:][:blank:]]} # "~(E)" is new

Besides the new parameters .sh.edchar, .sh.edmode, .sh.edcol,
..sh.edtext, and .sh.version, which have been documented well enough
(if underutilized), there now there are are many more (and it's
about time):

..sh.match[] : The most recent match and sub-pattern matches
substrings.
..sh.file : The pathname of the file than contains the current
command.
..sh.fun : The name of the current function that is being executed.
..sh.subshell : The current depth for subshells and command
substitution.
..sh.name : script script name
..sh.fun : current function name
..sh.subscript
..sh.value

The new printf %T directive makes all the usual C.U.S. date-time
queries ("last day in month...?", "how many days between...?",
"julian day number of...?") now officially obsolete. It even has
a simple natural language interface:

$ printf '%(%Y-%m-%dT%H:%MZ)T' 'day before yesterday'

There are a few new operators for here-documents:

<< becomes the
contents of the here-document after any parameter expansion, command
substitution, and arithmetic substitution occur.

.... and byte offsets for file descriptors:

<# ((expr)) : In addition, $(n<#) expands to the current byte offset
for file descriptor n. (ksh93r+)
># ((expr)) : In addition, $(n<#) expands to the current byte offset for file descriptor n. (ksh93r+)
"SEEK_HOLE", "EOF", and "HOLE" are substitutable parameters.

You didn't know that ksh(1) is an object-oriented language? ksh93
has always had it... via an unreleased library (typeset -T) :(

https://mailman.research.att.com/pipermail/ast-developers/20 04q3/000082.html

.... Nested variables too, upon which its O.O. is based:

$ food=(
[meat]=(
integer quantity=100
float price=10.40
)
[milk]=(
integer quantity=100
float price=2.05
)
)
$ print ${food[meat].price}
10.40

(Now, if only ksh builtin networking (/dev/@(tcp|udp)/) was
correctly compiled on every Unix host!....)

With the AST (AT&T Software Toolkit) library included with
ksh93, threads have always been available (coshell), and much,
much more: The ksh93 toolkit comes with a script compiler
(shcomp), a cscope-like relational database via the Kornshell
Information Abstraction (KIA) database produced by the undocumented
-D option and browsed by freely available GUI and TUI browsers
(ciao/cql), and a profiler: pfksh, rpfksh, or via script:

"profiler.ksh93"
https://mailman.research.att.com/pipermail/ast-users/2006q3/ 001357.html

(I wrote one too; mine's better!)

> I'm starting to think I might be smarter to just go with bash. At my
> usage level its very close.

Yes, I'm a ksh93 advocate, but my criticism of bash(1),
despite all the above, has nothing intrinsically to do with
just an enumeration of features. I'm a practical person, and
understand 80% of programmers use 20% of available features
of a language. Indeed, the ubiquity of open-source bash
(before the ksh sourcebase was made available) was and is
an invaluable contribution to the Unix community.

What I do decry is a language that subjugates design elegance
to mere "featuritis", codified by this old language designer's
Three Laws of Language Design, thus:

(1) What _should_ work, _must_ work!
(2) Provide _functionality_, not _features_, at well-defined
levels of abstraction.
(3) In context of the above, the language designer must never,
_ever_ tell the programmer what s/he can or can't do!

That is to say, k/sh (and bash) is and should never become a
perl/python/ruby. Its design was an almost foreordained reflection
of the Unix API, wherein shell's very-high-level abstraction of
redirection and pipes so well explicates the design elegance of
Unix. I respect the job that DGK has done in maintaining and
extending ksh, as much for the features that he _hasn't_ implemented
as the ones he has. All this extra kruft is what dynamic loading of
shared libraries (builtin -f) are for.

For instance, I think I've discovered a way to turn any script --
without modification! -- into a host-independent GUI. Stay tuned!

Ksh(1) is not completely innocent -- its early versions were
buggy messes, and the newest features are currently under-
documented... or not documented at all. Indeed, my major grievance
with ksh93 is that the latest features have been for me documented
only "accidentally" by reading the developers' forums or the
changelogs. *Grrr!*

By way of anecdote, long ago I emailed Chet Ramey (bash author) and
asked that he correctly emulate a facet of sh(1) that had been
implemented (and documented!) since version 7 Unix -- it was
breaking all of my scripts! He replied that it was original a
misfeature (wrong: I worked with Bill Joy at Berkeley), was not
used or important (what!?). He suggested I use the --posix option
to get the requested effect (not default), and that I was being
"disingenuous." *Sigh.* He just doesn't "get it."

A restatement to this effect can be seen on a past thread:

http://groups.google.com/group/comp.unix.shell/browse_thread /thread/41117551288a55fa/4e4cf34fc5c9e99e?lnk=st&q=#4e4cf34f c5c9e99e

My apologies for "going off" like this, and for getting somewhat
off topic.

=Brian