[arch-projects] [dbscripts] [PATCH v2 1/5] Use even more bashisms.

[Eli Schwartz]

On 02/20/2018 06:59 AM, Emil Velikov wrote:
> Disclaimer: the following is a bit subtle topic, so I hope it doesn't
> spur a lot of off-topic.

Eh, I don't mind.

> Is there any performance or other technical benefit to using more bashisms?
> 
> Reason being, that I am slowly going through different parts of Arch
> making it zsh friendly.
> While keeping the code brief and legible, of course.
> Guessing that I've picked the wrong hobby?

I think you'll probably find that few people write zsh scripts for
non-interactive use. I'm not really sure what the point would be,
considering it has a nonstandard syntax (bash is ubiquitous, zsh is
not), and many people who would know bash would not know zsh (like me
for example).

AFAIK zsh should more or less run either bash or POSIX sh scripts just
fine if you invoke it via a symlink named `sh` or `bash`, because zsh
has a bash compatibility mode. I have no idea whether that bash
compatibility mode fixes subtle things like the fact that zsh arrays are
1-indexed while bash arrays are 0-indexed, but if I had to guess,
probably not.

...

I can see some compelling reasons to write scripts targeting POSIX sh as
a baseline, which is being *sh* friendly, not zsh friendly.
But, for projects that make heavy use of bashisms anyways, I dislike
using POSIX because it implies that sh will be supported in any way when
it really won't be. Essentially, I prefer to go "all in".

As for why you'd want them, bashisms generally look cleaner IMHO, and
they add a great deal of power and flexibility to the shell. Things like
[[ ... ]] are just a lot more sane in basically every way, shell
arithmetic uses proper operators, etc.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-projects/attachments/20180220/1b26c759/attachment.asc>