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 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.

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 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 "$@" ;}

On Jan 7, 4:43pm, rea...@newsguy.com 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.

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....ed6773be861c72

=Brian

Icarus Sparry <usenet@icarus.freeuk.com> 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.

bsh <brian_hiles@rocketmail.com> 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.

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

> bsh <brian_hiles@rocketmail.com> 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.

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 <http://cfaj.freeshell.org/shell/>
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

Icarus Sparry <usenet@icarus.freeuk.com> 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.