All, There is a lot I like about zsh, but almost an equal amount I don't. The problem is how to handle adapting the 2566 POSIX and bash scripts I have to be zsh compatible. The biggest issues are parameter-expansions, 1's indexing, and issues with 'type' and other builtins being just enough different that my existing scripts break when using zsh as the interpreter. Is there any collection of aliases, tweaks, brute-force sed scripts, etc.. that I could look at an pull parts from to handle most of the issues? For example with 'type', I can alias it to 'whence', but the documentation for it is of little help with the expected behavior for type itself, e.g. type [ -wfpamsS ] name ... Equivalent to whence -v. at http://zsh.sourceforge.net/Doc/Release/Shell-Builtin-Commands.html, but the options [ -wfpamsS ] largely have no effect on how type behaves. Then what to do with a large portions of the scripts that rely heavily on string indexing and C-style for loops? The KSH_ARRAYS options is a temporary bandaid for C-style loops, but that injects zsh incompatibility and the documentation is absent on its effect on string indexing (e.g. ${foo:offset:length}). Then what to do about the non-existing expansions such as ${foo^^} (uppercase) and ${foo,,} (lowercase), etc.. In looking for solutions, I want to stay with core zsh solution, instead of plugins, modules, etc... Is there some collection of information that helps with this transition process, or is it largely a script-by-script rewrite to make the scripts compatible? -- David C. Rankin, J.D.,P.E.
May I ask why you want to port bash scripts to zsh? Roman.
On 06/10/2019 12:41 AM, Roman Perepelitsa wrote:
> May I ask why you want to port bash scripts to zsh?
>
So when I choose zsh as the only shell installed, things will continue to
work. The easy answer is install all shells, but on storage critical systems
has a distinct downside. That's why I am curious whether there is a collection
of information that can help in the transition.
--
David C. Rankin, J.D.,P.E.
On Mon, Jun 10, 2019 at 4:44 PM David C. Rankin
<drankinatty@suddenlinkmail.com> wrote:
> So when I choose zsh as the only shell installed, things will continue to
> work. The easy answer is install all shells, but on storage critical systems
> has a distinct downside. That's why I am curious whether there is a collection
> of information that can help in the transition.
On my Linux box sh is 100KB, bash is 1.1MB and zsh is 4.3MB. If you
are space constrained, zsh may not be the best choice.
Going back to your original question, I'm not aware of any tools for
automatic translation of bash code to zsh. It's likely that your
requirements are unique. Usually systems that can afford to have zsh
can also afford to have bash, so no translation is necessary.
Roman.
On 2019-06-10 7:53 a.m., Roman Perepelitsa wrote:
> automatic translation of bash code to zsh. It's likely that your
> requirements are unique. Usually systems that can afford to have zsh
> can also afford to have bash, so no translation is necessary.
>
In my case I didn't want the bother of having to learn the
idiosyncrasies of two shells. I picked one and was hoping to never have
to learn the other. If I was planning to transition from bash to zsh,
I'd be hoping to subsequently avoid bash altogether and thus go through
the conversion trouble once but then forget about bash and do all
further work in zsh. So space considerations would be the least of my
motives. Just me, but zsh syntax is so abstruse that not only learning
it, but also trying to remember the differences vis a vis bash, would
seem brain blowing.
So it seems David will have to do it line by line.
On Sun, Jun 9, 2019 at 5:34 PM David C. Rankin <drankinatty@suddenlinkmail.com> wrote: > > Is there any collection of aliases, tweaks, brute-force sed scripts, etc.. > that I could look at an pull parts from to handle most of the issues? First thing -- how are these scripts executed? E.g., are they run as standalone processes via interpreter named in a "#!" line at the top, or are they somehow pulled into an interactive shell, or something else? If using the "#!" interpreter, the first thing to try is simply to symlink that name to your zsh binary. When invoked as (a path ending in) "bash" or "sh" (or "ksh"), zsh enters a compatibility mode that will resolve the most common issues. You can then work on specific problems with any scripts that are still failing. This compatibility mode differs from setting individual options such as KSH_ARRAYS, but can be fairly closely duplicated by using the "emulate" command. If the scripts are intended to become the bodies of shell functions, try adding "emulate -L sh" at the top. > Then what to do about the non-existing expansions such > as ${foo^^} (uppercase) and ${foo,,} (lowercase), etc.. These are handled with (in those specific examples) ${foo:u} and ${foo:l}. In fact ^^ has a completely different meaning in zsh, so you will have to do a search-and-replace for those kinds of nonstandard tricks.
On 06/10/2019 12:34 PM, Ray Andrews wrote:
> On 2019-06-10 7:53 a.m., Roman Perepelitsa wrote:
>> automatic translation of bash code to zsh. It's likely that your
>> requirements are unique. Usually systems that can afford to have zsh
>> can also afford to have bash, so no translation is necessary.
>>
> In my case I didn't want the bother of having to learn the idiosyncrasies of
> two shells. I picked one and was hoping to never have to learn the other. If
> I was planning to transition from bash to zsh, I'd be hoping to subsequently
> avoid bash altogether and thus go through the conversion trouble once but then
> forget about bash and do all further work in zsh. So space considerations
> would be the least of my motives. Just me, but zsh syntax is so abstruse that
> not only learning it, but also trying to remember the differences vis a vis
> bash, would seem brain blowing.
>
> So it seems David will have to do it line by line.
That's the interesting part. I have 2-decades of bash, which with the
bashisms makes that somewhat of a daunting challenge. The "2566 POSIX and bash
scripts" wasn't a guess, it was a 'find ~/scr -type f | wc -l' exercise. From
the days of loading Linux from floppy disks from boxed sets, you didn't really
have a lot of foresight as to the implications of shell choice, which is what
makes the shell differences now more acute.
So the path forward seems like leaving all shells installed the only
solution and migrate the needed scripts one at a time. We shall see how it goes.
--
David C. Rankin, J.D.,P.E.
On 06/10/2019 03:22 PM, Bart Schaefer wrote:
> This compatibility mode differs from setting individual options such
> as KSH_ARRAYS, but can be fairly closely duplicated by using the
> "emulate" command. If the scripts are intended to become the bodies
> of shell functions, try adding "emulate -L sh" at the top.
>
>> Then what to do about the non-existing expansions such
>> as ${foo^^} (uppercase) and ${foo,,} (lowercase), etc..
> These are handled with (in those specific examples) ${foo:u} and
> ${foo:l}. In fact ^^ has a completely different meaning in zsh, so
> you will have to do a search-and-replace for those kinds of
> nonstandard tricks.
Thank you Bart,
That seems like the logical path forward. I was sure hoping somebody already
had a handy-dandy parse & convert routine, but it looks like a normal convert
as you go. As I go through them I'll try and keep a list of the most common
bash/zsh conversions and notes of those cases where there is no 1-for-1
replacement. It will be an as-time-permits endeavour, but maybe we can catch
most issues.
--
David C. Rankin, J.D.,P.E.
On Mon, 2019-06-10 at 17:31 -0500, David C. Rankin wrote: > On 06/10/2019 03:22 PM, Bart Schaefer wrote: > > This compatibility mode differs from setting individual options such > > as KSH_ARRAYS, but can be fairly closely duplicated by using the > > "emulate" command. If the scripts are intended to become the bodies > > of shell functions, try adding "emulate -L sh" at the top. > > > > Then what to do about the non-existing expansions such > > > as ${foo^^} (uppercase) and ${foo,,} (lowercase), etc.. > > These are handled with (in those specific examples) ${foo:u} and > > ${foo:l}. In fact ^^ has a completely different meaning in zsh, so > > you will have to do a search-and-replace for those kinds of > > nonstandard tricks. > Thank you Bart, > > That seems like the logical path forward. I was sure hoping somebody already > had a handy-dandy parse & convert routine, but it looks like a normal convert > as you go. As I go through them I'll try and keep a list of the most common > bash/zsh conversions and notes of those cases where there is no 1-for-1 > replacement. It will be an as-time-permits endeavour, but maybe we can catch > most issues. The FAQ, section 2.1, should help, from the Etc directory of the distribution or http://zsh.sourceforge.net/FAQ/zshfaq02.html#l10 pws