[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 -- gentoo-user@lists.gentoo.org mailing list