[EMAIL PROTECTED] writes:
> So I'm interested in what I might run into. So far it looks like it
> would be ALMOST as easy as symlinking ksh to bash in /bin.
Uh, this sounds scary :)
> The two big things I see that will cause that not to work are lots of
> calls to `print' and that bash does not understand the easy way you
> can create an array in ksh:
> `set -A array somecmd'
> creating an array of the output of somecmd.
>
> So the print calls and array creation would cause failure in nearly
> all my scripts.
>
> Someone on comp.unix.shell pointed out I could create a
> `print() { echo -e "$@" }'
> function in bash and add that to my old ksh scripts. So that would
> cover the print calls in most cases but still pondering the array
> part.
I do not know about ksh, but if the former statement creates an array with
the i'th element containing the i'th word of somecmd's output, it should
work like this:
array=( $( somecmd ) )
If you need the i'th line, not the i'th word, do it like this, changing the
internal field separator to newlines only:
oldIFS=$IFS
IFS=$'\n'
array=( $( somecmd ) )
IFS=$oldIFS
If you want to keep your notation, something like this might work. If the
first parameter of a call to set is -A, it creates the array, or else it
calls the bash set builtin:
set ()
{
if [[ $1 == -A ]]
then
eval "$2=( $( $3 ) )"
else
set "$@"
fi
}
> I don't have so many with array calls but enough that it would be some
> work to fix.
>
> But back to your comments. "The bugs. [...]"
>
> Can you cite some actual examples of what you are talking about, with
> enough detail so I can see what you mean? Maybe include one or two of
> the workarounds you are tired of dealing with?
I also had trouble with some bash bugs(*), and have some workarounds in my
scripts, in case they run with older bash versions. But as I cannot ensure
the client systems run kash or zsh, I did not bother to learn them, and
chose bash as my shell. It's amazing what it can do, but I guess zsh and
ksh can do the same, or even more.
(*) One was that I once needed to escape backslashes in ${//...} notations,
but now I must not do so any more:
(( BASH_VERSINFO < 3 )) &&
ospath=${1//\\\\//} ||
ospath=${1//\\//}
The other problem was with the =~ notation and quoting of the regular
expression not being allowed any more. Workaround is to define a variable
(foo) with the expression: [[ "blabla" =~ $foo ]]
Wonko
--
[email protected] mailing list
