Christoph Biedl dixit: >Quite frankly, I haven't checked which shell implementation does not >follow the specification, if any, or if this is just another bashism.
This depends. If “local” is a “declaration utility” (like export and readonly), then dash does not follow the spec. If “local” is not a “declaration utility”, then bash and mksh don’t follow the spec (except for the next release explicitly permitting this). However, “local” is not in POSIX (or ksh93 nor ksh2020, for that matter) and is a Debian-local addition to the requirements for /bin/sh on Debian only. POSIX 2017/2018 is quiet on declaration utilities, they only show up in the minutes 535, and among them is: |Implementations are permitted to provide extensions that serve as |declaration utilities, such as 'typeset' or 'local', or even a way to |define a function that can behave as a declaration utility. Policy §10.4 is quiet on this as well. I’d still report this as a bug, severity important or normal, to dash for consistency and to match user expectations; declaration utilities in POSIX (XBD 3) are defined as “A utility which can take arguments that cause variable assignments (of the form varname=value) which will persist in the current shell environment.” and it stands to presume that, if “local” is present, it certainly fits this definition. Do note that “command” is a declaration utility forwarder, i.e. if “command” is followed by “export”, “readonly”, etc. it will also act as a declaration utility. bye, //mirabilos -- FWIW, I'm quite impressed with mksh interactively. I thought it was much *much* more bare bones. But it turns out it beats the living hell out of ksh93 in that respect. I'd even consider it for my daily use if I hadn't wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh
