7

I know that dash adheres quite closely to the POSIX standard, but I know that it's not 100.00% strict POSIX without any extras. The shell that comes closest/adheres exactly to the POSIX standard is as far as I know mrsh or yash with the POSIXly-correct flag set.

Now I want to know exactly which parts/functionalities of dash are not specified in the POSIX standard (without reading the entirety of POSIX.1-2017 and the source code of dash).

I already tried extensive googling (as far as I'm knowledgable enough for this topic) but who would have thought, it's exclusively results on what the differences between bash and dash are and how dash is very POSIX compliant and so on.

Improve this question
3
  • 1
    at least the local keyword and local vars are one such (ksh treats them differently from most others, so there's no standard for them).
    – ilkkachu
    Mar 27, 2022 at 15:35
  • FWIW, ikkachu's topic about local is dealt in this SO Q/A: stackoverflow.com/questions/18597697/…
    – A.B
    Mar 27, 2022 at 15:47
  • According to Wikipedia, "Dash implements support for neither internationalization and localization nor multi-byte character encoding (both required in POSIX)".
    – Devon
    Mar 28, 2022 at 9:16

1 Answer 1

Reset to default
4

Here is the start of an inventory of the extra features that dash and its builtins have over what's specified by POSIX.1-2017.

  • Supports local scope of variables and options via a local builtin (from original Ash in 1989).
  • Supports (in some builds) some -V/-E options as aliases for -o vi, -o emacs.
  • -I as alias to -o ignoreeof (all options have a single-letter equivalent so it can be tracked in $-, which you can make local with local).
  • Supports a -p / -o privileged option.
  • A -l option to start as login shell
  • its echo supports the -n option
  • its read supports a -p prompt option
  • its printf supports %f/e/E/g/G directives.
  • both its echo and printf support \e to output an ESC.
  • its [/test support -ef, -nt, -ot, <, > operators
  • its ulimit supports many more options that those specified by POSIX
  • handling of MAIL, MAILCHECK, MAILPATH variables.
Improve this answer
4
  • Does anyone know if there are any plans to add a more complete POSIX feature set to "dash"? At least in Debian, things like the set -o vi directive does not work at all.
    – Kajukenbo
    Mar 26 at 8:49
  • @Kajukenbo, set -o vi (or set -o emacs) works if you enable it at compile time (configure --with-libedit), but the point of dash is to provide a simple robust and efficient interpreter for the sh language that can be used for system()/popen() or interpret #! /bin/sh - scripts. It's not intended for interactive use. Look at shells like zsh or fish for that.
    – Stéphane Chazelas
    Mar 26 at 11:18
  • I get the point that it is supposed to be small and fast, but how can people claim dash to be POSIX complaint all the time if it is not? set -o vi is very clearly part of the standard for /bin/sh. FWIW, I have no interest in using something like zsh or fish. I guess I will just stick with ksh88-based implementations. I doubt a simple recompile will fix all of the discrepancies anyway. Thanks for the reply.
    – Kajukenbo
    Mar 26 at 12:42
  • @Kajukenbo, again dash supports set -o vi (note that in bash, the vi mode is also optional and can be disabled at build time). POSIX specifies a standard API. IMO, the shell's line editor does not belong there and should be removed from the standard or at least moved to the User Portability option. For instance, that line editor does not make sense on embedded systems. Note that ksh88 has many non-compliances and bugs, far more so than dash. If you want a more compliant shell, you can have a look at bosh or yash (each also coming with their own issues).
    – Stéphane Chazelas
    Mar 26 at 13:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .