• [ANN] ksh 93u+m/1.0.7

    From Martijn Dekker@21:1/5 to All on Fri Sep 15 15:37:37 2023
    XPost: comp.unix.shell

    Announcing: KornShell 93u+m/1.0.7
    https://github.com/ksh93/ksh

    Here is the seventh ksh 93u+m/1.0 bugfix release. It fixes a hang in
    command substitutions when combined with 'exec' and certain redirections.

    Further below is an overview of the main changes. For greater detail, see
    the NEWS file in the distribution. For complete detail, see the git(1)
    commit log, which has full documentation of every significant change.

    ### HOW TO GET IT ###

    Please download the source code tarball from our GitHub releases page: https://github.com/ksh93/ksh/releases
    To build, follow the instructions in README.md or src/cmd/ksh93/README.

    Or ask your distribution package manager to upgrade ksh to this version.

    ### ABOUT KSH ###

    KornShell (ksh) is a full-featured and very fast shell script interpreter
    and interactive command shell with a distinguished lineage: it is a direct descendant of the Bourne shell and, like its ancestor, was developed at
    AT&T, the birthplace of UNIX. ksh has been open source since 2000.

    But when AT&T terminated development in 2020, ksh was left buggy and unreliable. ksh 93u+m aims to fix this situation whilst maintaining and
    growing the tradition. For now, we are focusing mostly on fixing bugs and egregious flaws but we also prioritise backward compatibility, performance, portability, and occasionally adding a feature. Work on ksh 93u+m started in May 2020, based on the last AT&T stable release, ksh 93u+.

    Unique ksh features include discipline functions (every variable expansion
    or assignment can trigger a shell function call determining its value),
    static scoping of local variables in functions, the ability to define your
    own data types, customisable tilde expansion (new in 93u+m), a shell option
    for file system case (in)sensitivity detection for pathname expansion and
    file name completion (new in 93u+m), and much more.

    ### CONTRIBUTORS ###

    Main ksh 93u+m developers: Martijn Dekker, Johnothan King, hyenias

    Direct contributors: Andy Fiddaman, Anuradha Weeraman, atheik, Chase,
    Cy Schubert, Govind Kamat, Harald van Dijk, K. Eugene Carlson, Lev
    Kujawski, Marc Wilson, Phi, Ryan Schmidt, rymrg, Sterling Jensen,
    Trey Valenta, Vincent Mihalkovic

    Also includes backported contributions by: David Korn, Glenn Fowler,
    Lefteris Koutsofios, Siteshwar Vashisht, Kurtis Rader, Roland Mainz,
    Finnbarr P. Murphy, Lijo George, OpenSUSE ksh 93u+ patch authors, Red Hat
    ksh 93u+ path authors, Solaris ksh 93u+ patch authors, Debian ksh 93u+
    patch authors, Apple ksh 93u+ patch authors, Graphviz maintainers

    Many fixes have also been backported from the AT&T 93v- beta as well as the former AT&T ksh2020 project lead by Kurtis Rader and Siteshwar Vashisht; we appreciate and benefit from their work. Many thanks also to Siteshwar for graciously donating his 'ksh93' GitHub organisation account!

    ### HOW TO GET INVOLVED ###

    To report a bug, please open an issue at our GitHub page (see above). Alternatively, email me at martijn@inlv.org with your report.
    To get involved in development, read the brief policy information in
    README.md and then jump right in with a pull request or email a patch.
    Feel free to use Discussions to introduce yourself to the community.

    You can also join the mailing list/Google group at: https://groups.google.com/g/korn-shell

    ### MAIN CHANGES between ksh 93u+m/1.0.6 and 93u+m/1.0.7 ###

    - Fixed a hang in command substitutions (introduced in 93u+m/1.0.0) that was
    triggered when redirecting standard output within a command substitution,
    in combination with other factors. E.g., the following no longer hangs:
    { v=$(redirect 2>&1 1>&9); } 9>&1
    - Fixed a crash on trying to append an indexed array value to an unset name
    reference, e.g.: nameref unsetref; unsetref+=(foo bar). This now produces
    a "removing nameref attribute" warning before performing the assignment.
    - Fixed: assignments like name=(...) to arrays did not preserve the array
    and variable types; similarly, assigning an empty set () to a compound
    indexed array caused the -C attribute to be lost.
    - Fixed incorrect rejection of the tab key while reading input using the
    'read' built-in command.
    - Fixed a bug in printf %T: when using dates and times in the past, time
    zones for the present were incorrectly used, ignoring historical changes.

    ### MAIN CHANGES between ksh 93u+m/1.0.5 and 93u+m/1.0.6 ###

    - Fixed a serious regression in pathname expansion where quoted wildcard
    characters were incorrectly expanded if a pattern contains both a brace
    expansion and a variable expansion.
    - Fixed a bug where the command to launch a full-screen editor (^X^E in
    emacs and 'v' in vi) could cause the wrong command line to be edited
    if two shell sessions share a .sh_history file.

    ### MAIN CHANGES between ksh 93u+m/1.0.4 and 93u+m/1.0.5 ###

    - Fixed various bugs causing crashes.
    - Fixed many bugs in the emacs and vi line editors, in command completion,
    and in file name completion.
    - Fixed various bugs in the handling of quotes, backslash escapes and braces
    when processing shell glob patterns (e.g. in pathname expansion and 'case'). - ksh now throws a panic and exits if a read error (such as an I/O error)
    occurs while trying to read the next command(s) from a running script.
    - Fixed many bugs in 'printf' and 'print -f' built-in commands, including:
    . Multiple bugs causing incorrect output for relative date specifications,
    e.g., printf %T\\n 'exactly 20 months ago' now outputs a correct result.
    . More printf bugs with mix and match of % and %x$.
    . A data corruption bug when using %B with 'printf -v varname'.
    . A bug causing double evaluation of arithmetic expressions.
    - Fixed a bug where 'unset -f commandname', executed in a subshell, hides
    any built-in command by the same name for the duration of that subshell.
    - Fixed ${var/#/string} and ${var/%/string} (with anchored empty pattern)
    to work as on mksh, bash and zsh; these are no longer ineffective.
    - Fixed incorrect result of array slicing ${array[@]:offset:length} where
    'length' is a nested expansion involving an array.
    - Command names can now end in ':' as they can on other shells.
    - Fixed a spurious syntax error in compound assignments upon encountering a
    pair of repeated opening parentheses '(('.
    - Fixed spurious syntax error in ${parameter:offset:length}: the arithmetic
    expressions 'offset' and 'length' may now contain the operators ( ) & |.
    - Fixed a parsing bug in the declaration of .sh.math.* arithmetic functions.
    - Fixed nameref self-reference loop detection for more than two namerefs.
    - Several improvements to the POSIX compatibility mode.
    - Many more minor and/or esoteric bugfixes.

    ### MAIN CHANGES between ksh 93u+m/1.0.3 and 93u+m/1.0.4 ###

    - Fixed multiple scoping-related bugs in the += additive assignment operator.
    - A number of crashing bugs have been fixed.
    - Various fixes for the Haiku operating system, notably 'ulimit -a' now works. - Fixed the expansion of out-of-range \n back references in the string part of
    ${parameter//pattern/string}. For example: v=AB; echo "${v/@(A)B/\0:\1:\2}"
    now yields 'AB:A:' instead of 'AB:A:\2'.
    - Fixed quoted '!', '^' and '-' within [bracket] expressions in glob patterns;
    single or double quotes failed to disable their operator behaviour.
    - Fixed a bug introduced on 2021-04-04 that incorrectly allowed 'typeset' to
    turn off the readonly and export attributes on a readonly variable.
    - In the emacs line editor, the Ctrl+R reverse-search prompt is now visually
    distinct from a literal control character ("^R: " instead of "^R").
    - In the vi line editor, fixed the behaviour of 'C', 'c$' and 'I' to be
    consistent with standard vi(1) and with Bolsky & Korn (1995, p. 121).
    - Aliases for many GNU long options have been added to the /opt/ast/bin
    built-in commands. Additionally, 'kill -s' now has a --signal long option
    alias compatible with the util-linux option.
    - Backported support for 'print -u p' from ksh 93v- for compatibility with
    scripts written for 93v-/ksh2020 (this is equivalent to 'print -p').

    ### MAIN CHANGES between ksh 93u+m/1.0.2 and 93u+m/1.0.3 ###

    This point release fixes the following:
    - An old bug in history expansion (set -H) where any use of the history
    comment character caused processing to be aborted as if it were an invalid
    history expansion.
    - A bug in command line options processing that caused short-form
    option equivalents on some built-in commands to be ignored after one use,
    e.g., the new read -a equivalent of read -A.
    - Ksh freezing or using excessive memory if HISTSIZE is assigned a
    pathologically large value.
    - A bug that caused ksh in the vi editor mode to crash or produce invalid
    completions if ESC = was used at the beginning of a line.

    ### MAIN CHANGES between ksh 93u+m/1.0.1 and 93u+m/1.0.2 ###

    This bugfix release fixes the interactive shell crashing when one of the predefined aliases (currently 'history' and 'r') is redefined, whether from
    a profile/kshrc script or manually. This crash occurred in two scenarios:
    1. when redefining and then unsetting a predefined alias;
    2. when redefining a predefined alias and then executing a shell script that
    does not begin with a #! path.

    ### MAIN CHANGES between ksh 93u+m/1.0.0 and 93u+m/1.0.1 ###

    This is an urgent bugfix release that removes an incorrect exec
    optimization that was capable of terminating the execution of scripts prematurely in certain corner cases. It is known to make the build scripts
    of GNU binutils produce corrupted results if ksh is used as /bin/sh.
    See https://github.com/ksh93/ksh/issues/507 for more information.

    ### MAIN CHANGES between ksh 93u+ and 93u+m/1.0.0 ###

    Roughly a thousand bugs have been fixed, including many serious/critical
    bugs. See the NEWS file for more information, and the git commit log for complete documentation of every fix. Incompatible changes have been
    minimised, but not at the expense of fixing bugs. For a list of
    potentially incompatible changes, see src/cmd/ksh93/COMPATIBILITY.

    Though there was a "no new features, bugfixes only" policy, some new
    features were found necessary, either to fix serious design flaws or to complete functionality that was evidently intended, but not finished.
    Below is a summary of these new features.

    New command line editor features:

    - The forward-delete and End keys are now handled as expected in the
    emacs and vi built-in line editors.

    - In the vi and emacs line editors, repeat counts can now also be used for
    arrow keys and the forward-delete key, e.g., <ESC> 7 <left-arrow> works.

    - Various keys on extended PC keyboards are now handled as expected in the
    emacs and vi built-in line editors.

    New shell language features:

    - Pathname expansion (a.k.a. globbing) now never matches the special names
    '.' (current directory) and '..' (parent directory). This change makes a
    pattern like .* useful; it now matches all hidden files (dotfiles) in the
    current directory, without the harmful inclusion of '.' and '..'.

    - Tilde expansion can now be extended or modified by defining a .sh.tilde.get
    or .sh.tilde.set discipline function. See the manual for details.

    - The &>file redirection shorthand (for >file 2>&1) is now available for all
    scripts and interactive sessions and not only for profile/login scripts.

    - Arithmetic expressions in native ksh mode no longer interpret a number
    with a leading zero as octal in any context. Use 8#octalnumber instead
    (e.g. 8#400 == 256). Arithmetic expressions now also behave identically
    within and outside ((...)) and $((...)). If the POSIX mode is turned on,
    a leading zero now denotes an octal number in all arithmetic contexts.

    New features in built-in commands:

    - Usage error messages now show the --help/--man self-documentation options.

    - Path-bound built-ins (such as /opt/ast/bin/cat) can now be executed by
    invoking the canonical path, so the following will now work as expected:
    $ /opt/ast/bin/cat --version
    version cat (AT&T Research) 2012-05-31

    - 'cd' now supports an -e option that, when combined with -P, verifies
    that $PWD is correct after changing directories; this helps detect
    access permission problems. See:
    https://www.austingroupbugs.net/view.php?id=253

    - 'command -x' now looks for external commands only, skipping built-ins.
    In addition, its xargs-like functionality no longer freezes the shell on
    Linux and macOS, making it effectively a new feature on these systems.

    - 'printf' now supports a -v option as in bash. This assigns formatted
    output directly to variables, which is very fast and will not strip
    final newline (\n) characters.

    - 'redirect' now checks if all arguments are valid redirections before
    performing them. If an error occurs, it issues an error message instead
    of terminating the shell.

    - 'return', when used to return from a function, can now return any
    status value in the 32-bit signed integer range, like on zsh. However,
    due to a traditional Unix kernel limitation, $? is still trimmed to its
    least significant 8 bits whenever a shell or subshell exits.

    - 'suspend' now refuses to suspend a login shell, as there is probably no
    parent shell to return to and the login session would freeze.

    - 'test'/'[' now supports all the same operators as [[ (including =~,
    \<, \>) except for the different 'and'/'or' operators. Note that
    'test'/'[' remains deprecated due to its unfixable pitfalls;
    [[ ... ]] is recommended instead.

    - 'times' now gives high precision output in a POSIX compliant format.

    - 'type'/'whence': Two bash-like flags were backported from ksh 93v-:
    - 'whence -P/type -P' is an alias to the existing -p flag.
    - 'whence -t/type -t' will print only the type of a command in a
    simple format that is designed to be easy to use for scripts.

    - 'typeset' has a new '-g' flag that forces variables to be created or
    modified at the global scope regardless of context, as on bash 4.2+.

    - 'typeset' now gives an informative error message if an incompatible
    combination of options is given.

    - 'ulimit': Added three options inspired by bash:
    - 'ulimit -k' sets the maximum number of kqueues.
    - 'ulimit -P' sets the maximum number of pseudo-terminals.
    - 'ulimit -R' sets the maximum time in microseconds a real-time process
    can run before blocking.
    Note that not all operating systems support the limits set by these options.

    - 'whence -v/-a' now reports the location of autoloadable functions.

    New features in shell options:

    - When the -b/--notify shell option is on and the vi or emacs/gmacs shell
    line editor is in use, 'Done' and similar notifications from completed
    background jobs are now inserted directly above the line you're typing,
    without affecting your command line display.

    - A new --functrace long-form shell option causes the -x/--xtrace option's
    state and the DEBUG trap action to be inherited by function scopes instead
    of being reset to default. Changes made to them within a function scope
    still do not propagate back to the parent scope. Similarly, this option
    also causes the DEBUG trap action to be inherited by subshells.

    - A new --globcasedetect shell option is added on operating systems where
    we can check for a case-insensitive file system (currently Linux, macOS,
    QNX 7.0+, and Windows/Cygwin). When this option is turned on, pathname
    expansion (globbing), as well as tab completion on interactive shells,
    automatically become case-insensitive depending on the file system.
    This is separately determined for each pathname component.

    - Enhancement to -G/--globstar: symbolic links to directories are now
    followed if they match a normal (non-**) glob pattern. For example, if
    '/lnk' is a symlink to a directory, '/lnk/**' and '/l?k/**' now work as
    you would expect.

    - The new --histreedit and --histverify options modify history expansion
    (--histexpand). If --histreedit is on and a history expansion fails, the
    command line is reloaded into the next prompt's edit buffer, allowing
    corrections. If --histverify is on, the results of a history expansion are
    not immediately executed but instead loaded into the next prompt's edit
    buffer, allowing further changes.

    - A new --nobackslashctrl shell option disables the special escaping
    behaviour of the backslash character in the emacs and vi built-in editors.
    Particularly in the emacs editor, this makes it much easier to go back,
    insert a forgotten backslash into a command, and then continue editing
    without having your next arrow key replace your backslash with garbage.

    - A new --posix shell option has been added to ksh 93u+m that makes the
    ksh language more compatible with other shells by following the POSIX
    standard more closely. See the manual page for details. It is enabled by
    default if ksh is invoked as sh, otherwise it is disabled by default.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Muttley@dastardlyhq.com@21:1/5 to Martijn Dekker on Fri Sep 15 15:11:45 2023
    XPost: comp.unix.shell

    On Fri, 15 Sep 2023 15:37:37 +0100
    Martijn Dekker <martijn@inlv.demon.nl> wrote:
    But when AT&T terminated development in 2020, ksh was left buggy and >unreliable. ksh 93u+m aims to fix this situation whilst maintaining and

    I used it back in the day and never found it buggy or unreliable. No doubt as with all mature software where the devs need to justify their continued update of it, a load of mostly useless features were added which they found interesting
    to do and added a load of bugs in the process.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Janis Papanagnou@21:1/5 to Muttley@dastardlyhq.com on Fri Sep 15 17:46:39 2023
    XPost: comp.unix.shell

    On 15.09.2023 17:11, Muttley@dastardlyhq.com wrote:
    On Fri, 15 Sep 2023 15:37:37 +0100 Martijn Dekker
    <martijn@inlv.demon.nl> wrote:
    But when AT&T terminated development in 2020, ksh was left buggy
    and unreliable. ksh 93u+m aims to fix this situation whilst
    maintaining and

    I used it back in the day and never found it buggy or unreliable.

    Uh-oh! - There were bugs, and even most obvious ones had been left
    unfixed for years. (So glad that Martijn & Co. provides reliable
    updates.) Despite these bugs I was using ksh as my shell of choice
    since the early 1990's.

    No doubt as with all mature software where the devs need to justify
    their continued update of it, a load of mostly useless features were
    added which they found interesting to do and added a load of bugs in
    the process.

    Weren't David and Glenn working on ksh's features until they left?
    What were (in your opinion) these "mostly useless features" that
    you have in mind?

    I'm asking because the subset of bugs I stumbled across had often
    been (also) in old functionality, and myself using newer features
    of ksh that are useful to me and (though not 100% free of bugs -
    and which complex software would claim so?) typically just work.

    Janis

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Muttley@dastardlyhq.com@21:1/5 to Janis Papanagnou on Sat Sep 16 08:58:35 2023
    XPost: comp.unix.shell

    On Fri, 15 Sep 2023 17:46:39 +0200
    Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
    On 15.09.2023 17:11, Muttley@dastardlyhq.com wrote:
    On Fri, 15 Sep 2023 15:37:37 +0100 Martijn Dekker
    <martijn@inlv.demon.nl> wrote:
    But when AT&T terminated development in 2020, ksh was left buggy
    and unreliable. ksh 93u+m aims to fix this situation whilst
    maintaining and

    I used it back in the day and never found it buggy or unreliable.

    Uh-oh! - There were bugs, and even most obvious ones had been left
    unfixed for years. (So glad that Martijn & Co. provides reliable

    I never came across any. But then I don't use shell as a substitute interpreted language.

    No doubt as with all mature software where the devs need to justify
    their continued update of it, a load of mostly useless features were
    added which they found interesting to do and added a load of bugs in
    the process.

    Weren't David and Glenn working on ksh's features until they left?
    What were (in your opinion) these "mostly useless features" that
    you have in mind?

    Look at the list of updates he listed in that post. I looked at them and couldn't see a time at which I'd ever use a single one.

    Seems to me far too many people try and use shell script way beyond what it
    was intended to do - ie navitage the file system, link commands together and job control - and use it where they'd be far better off simply using perl or python (or even awk) which leads shell authors to bung in features no sane person in their right mind would ever need, never mind use.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From candycanearter07@21:1/5 to Muttley@dastardlyhq.com on Sat Sep 16 11:56:54 2023
    XPost: comp.unix.shell

    On 9/16/23 03:58, Muttley@dastardlyhq.com wrote:
    Seems to me far too many people try and use shell script way beyond what it was intended to do - ie navitage the file system, link commands together and job control - and use it where they'd be far better off simply using perl or python (or even awk) which leads shell authors to bung in features no sane person in their right mind would ever need, never mind use.


    I agree, being so simple and being *right there* draws in beginners who
    don't know other languages I think.

    --
    --
    user <candycane> is generated from /dev/urandom

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kenny McCormack@21:1/5 to no@thanks.net on Sat Sep 16 17:27:09 2023
    XPost: comp.unix.shell

    In article <ue4mom$3t6o2$2@dont-email.me>,
    candycanearter07 <no@thanks.net> wrote:
    On 9/16/23 03:58, Muttley@dastardlyhq.com wrote:
    Seems to me far too many people try and use shell script way beyond what it >> was intended to do - ie navitage the file system, link commands together and >> job control - and use it where they'd be far better off simply using perl or >> python (or even awk) which leads shell authors to bung in features no sane >> person in their right mind would ever need, never mind use.


    I agree, being so simple and being *right there* draws in beginners who
    don't know other languages I think.

    Poppycock.

    I especially love the phrase (quoted above): simply using perl or python

    Yeah, right...

    --
    Faced with the choice between changing one's mind and proving that there is
    no need to do so, almost everyone gets busy on the proof.

    - John Kenneth Galbraith -

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Janis Papanagnou@21:1/5 to Muttley@dastardlyhq.com on Sat Sep 16 23:46:04 2023
    XPost: comp.unix.shell

    On 16.09.2023 10:58, Muttley@dastardlyhq.com wrote:
    On Fri, 15 Sep 2023 17:46:39 +0200
    Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
    On 15.09.2023 17:11, Muttley@dastardlyhq.com wrote:

    I used it back in the day and never found it buggy or unreliable.

    Uh-oh! - There were bugs, and even most obvious ones had been left
    unfixed for years. (So glad that Martijn & Co. provides reliable

    I never came across any. But then I don't use shell as a substitute interpreted
    language.

    Not perfectly sure I understand the "a substitute interpreted language"
    here correctly. For sure a shell is (and always was; since Bourne) an interpreted language. (And David Korn certainly, and correctly, named
    ksh as what it was intended, a "Command and Programming Language".)

    The observation that even simple repeating tasks can be collected in a imperative language frame, tasks that had there origin as command line commands, is and was just a consistent view on the shell's abilities
    and shell's design.


    No doubt as with all mature software where the devs need to justify
    their continued update of it, a load of mostly useless features were
    added which they found interesting to do and added a load of bugs in
    the process.

    Weren't David and Glenn working on ksh's features until they left?
    What were (in your opinion) these "mostly useless features" that
    you have in mind?

    Look at the list of updates he listed in that post. I looked at them and couldn't see a time at which I'd ever use a single one.

    I cannot guess which ones on that list you have in mind. Almost all bug
    fixes I see for "u+m" are fixes of original AT&T ksh, so you say you
    haven't used the mentioned Kornshell's features? (I certainly used most
    of them over the decades.)


    Seems to me far too many people try and use shell script way beyond what it was intended to do - ie navitage the file system, link commands together and job control -

    (This appears to me to be a very limited application view.) - Are you
    saying here that already in 1988 (or 1993 ?) Korn (et al.) provided
    extensions to Bourne sh that were unnecessary? - You think a shell is
    (and should be) just a command line processor (like MS cmd, or so)?
    Even Bourne sh had while/for/case/if/... and signal traps.

    What later shells (and the POSIX standard) added was builtin features
    to make it possible to efficiently work on the growing performance
    demands with handled volumes and number or size of handled objects.

    It's really hard to understand (from your statements) your view what
    you think a shell should provide and what it shouldn't. Some examples
    would help.

    and use it where they'd be far better off simply using perl or
    python (or even awk)

    Perl and python are non-standard, and also not simple, you have to
    learn these new languages. There should be a reason to learn them!
    (Myself I use shell and never experienced a necessity to switch
    to perl or python.) Awk (a language I extensively also use) is not
    suited for the tasks I typically do with shell.

    which leads shell authors to bung in features no sane
    person in their right mind would ever need, never mind use.

    Before diving into the details it would be good to know whether you
    are criticizing Martijn's "ksh93 u+m" fixes, or AT&T's ksh93 or ksh88
    and POSIX sh.

    (OTOH, if you don't use the post-Bourne shell features it's probably
    pointless to discuss.)

    Janis

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Janis Papanagnou@21:1/5 to All on Sat Sep 16 23:56:10 2023
    XPost: comp.unix.shell

    On 16.09.2023 18:56, candycanearter07 wrote:
    On 9/16/23 03:58, Muttley@dastardlyhq.com wrote:
    Seems to me far too many people try and use shell script way beyond
    what it
    was intended to do - ie navitage the file system, link commands
    together and
    job control - and use it where they'd be far better off simply using
    perl or
    python (or even awk) which leads shell authors to bung in features no
    sane
    person in their right mind would ever need, never mind use.


    I agree, being so simple and being *right there* draws in beginners who
    don't know other languages I think.

    Shell is no simple language, it has a lot of pitfalls; beginners should
    be carefully trained or guided, or kept away from shell programming!
    Knowledge of "other languages" is of limited use to master shell with
    all its quirks and dangers. Note also that shell is standard and part
    of every Unix system; in the 1990's there was no perl or python in the commercial standard environments, which was often even forbidden to
    be installed by a (very reasonable) security policy or by portability
    standards guidelines.

    Janis

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kaz Kylheku@21:1/5 to Muttley@dastardlyhq.com on Sun Sep 17 00:11:55 2023
    XPost: comp.unix.shell

    On 2023-09-16, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
    On Fri, 15 Sep 2023 17:46:39 +0200
    Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
    Uh-oh! - There were bugs, and even most obvious ones had been left
    unfixed for years. (So glad that Martijn & Co. provides reliable

    I never came across any. But then I don't use shell as a substitute interpreted
    language.

    Basically ...

    "Bugs that do not affect me do not exist. People who run into bugs are
    using the software wrong. Nobody should ever work on bugs that don't
    affect me, or features that I don't personally intend to use."

    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @Kazinator@mstdn.ca
    NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kenny McCormack@21:1/5 to All on Sun Sep 17 15:09:53 2023
    XPost: comp.unix.shell

    In article <ue74ag$dths$1@dont-email.me>, <Muttley@dastardlyhq.com> barfed out:
    ...
    beyond and way in languages clear doing. yet over writing would who a
    the you leave out shell like of People think the code suggest know wet
    crap then it explains perl any who they years in you what paper I've to a >python or of hack kind write couldn't by can written is programming their >code sysadmins. scripting steer they're bag seen lot If I people of of

    Someone just didn't get enough love as a child.

    They say that people like this weren't breast-fed long enough (if at all).
    That explains a lot.

    --
    The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
    http://user.xmission.com/~gazelle/Sigs/Windows

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Muttley@dastardlyhq.com@21:1/5 to Kenny McCormack on Sun Sep 17 15:00:32 2023
    XPost: comp.unix.shell

    On Sat, 16 Sep 2023 17:27:09 -0000 (UTC)
    gazelle@shell.xmission.com (Kenny McCormack) wrote:
    In article <ue4mom$3t6o2$2@dont-email.me>,
    candycanearter07 <no@thanks.net> wrote:
    On 9/16/23 03:58, Muttley@dastardlyhq.com wrote:
    Seems to me far too many people try and use shell script way beyond what it >>> was intended to do - ie navitage the file system, link commands together and

    job control - and use it where they'd be far better off simply using perl or

    python (or even awk) which leads shell authors to bung in features no sane >>> person in their right mind would ever need, never mind use.


    I agree, being so simple and being *right there* draws in beginners who >>don't know other languages I think.

    Poppycock.

    I especially love the phrase (quoted above): simply using perl or python

    Yeah, right...

    If writing code in scripting languages like perl or python is beyond you then
    I would suggest you steer clear of any kind of programming and leave it to people who know what they're doing. People who couldn't hack their way out
    of a wet paper bag yet think they can write code in shell explains a lot
    of the crap I've seen over the years written by sysadmins.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Muttley@dastardlyhq.com@21:1/5 to Janis Papanagnou on Sun Sep 17 15:14:33 2023
    XPost: comp.unix.shell

    On Sat, 16 Sep 2023 23:46:04 +0200
    Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
    On 16.09.2023 10:58, Muttley@dastardlyhq.com wrote:
    On Fri, 15 Sep 2023 17:46:39 +0200
    Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
    On 15.09.2023 17:11, Muttley@dastardlyhq.com wrote:

    I used it back in the day and never found it buggy or unreliable.

    Uh-oh! - There were bugs, and even most obvious ones had been left
    unfixed for years. (So glad that Martijn & Co. provides reliable

    I never came across any. But then I don't use shell as a substitute >interpreted
    language.

    Not perfectly sure I understand the "a substitute interpreted language"
    here correctly. For sure a shell is (and always was; since Bourne) an >interpreted language. (And David Korn certainly, and correctly, named
    ksh as what it was intended, a "Command and Programming Language".)

    A substitute for interpreted languages such as perl or python. Ie easy to
    write with a lot of functionality but slow as hell. If i'd said scripting languages you'd have been even more confused given we're discussing shell script.

    Seems to me far too many people try and use shell script way beyond what it >> was intended to do - ie navitage the file system, link commands together and

    job control -

    (This appears to me to be a very limited application view.) - Are you
    saying here that already in 1988 (or 1993 ?) Korn (et al.) provided >extensions to Bourne sh that were unnecessary? - You think a shell is
    (and should be) just a command line processor (like MS cmd, or so)?
    Even Bourne sh had while/for/case/if/... and signal traps.

    Yes it does, and its as ugly and hacky as fuck with idiotic syntactic
    quirks just like most shells. No sensible dev uses shell beyond kicking something off and maybe simply monitoring. Sysops however whom mostly can't code well to save their lives seem to think programming in shell is normal because often thats all they know.

    It's really hard to understand (from your statements) your view what
    you think a shell should provide and what it shouldn't. Some examples
    would help.

    Sub shell, co processes, process substitution, lists, idiotic numeric
    syntax with (( )) everywhere (not to be confused with () or [[]] !) and
    make sure you use your whitespace correctly because [hacky historical reasons].

    etc

    and use it where they'd be far better off simply using perl or
    python (or even awk)

    Perl and python are non-standard, and also not simple, you have to
    learn these new languages. There should be a reason to learn them!

    face <- palm

    (Myself I use shell and never experienced a necessity to switch
    to perl or python.) Awk (a language I extensively also use) is not

    I rest my case.

    suited for the tasks I typically do with shell.

    So basically you know essentially squat about real programming yet you're advocating that shell is great for dev. Got it. Reminds me of people who
    only know BASIC and wonder why any other language would ever be needed.

    which leads shell authors to bung in features no sane
    person in their right mind would ever need, never mind use.

    Before diving into the details it would be good to know whether you
    are criticizing Martijn's "ksh93 u+m" fixes, or AT&T's ksh93 or ksh88
    and POSIX sh.

    The list posted a few days ago.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Muttley@dastardlyhq.com@21:1/5 to Kaz Kylheku on Sun Sep 17 15:17:16 2023
    XPost: comp.unix.shell

    On Sun, 17 Sep 2023 00:11:55 -0000 (UTC)
    Kaz Kylheku <864-117-4973@kylheku.com> wrote:
    On 2023-09-16, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
    On Fri, 15 Sep 2023 17:46:39 +0200
    Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
    Uh-oh! - There were bugs, and even most obvious ones had been left >>>unfixed for years. (So glad that Martijn & Co. provides reliable

    I never came across any. But then I don't use shell as a substitute >interpreted
    language.

    Basically ...

    "Bugs that do not affect me do not exist. People who run into bugs are
    using the software wrong. Nobody should ever work on bugs that don't
    affect me, or features that I don't personally intend to use."

    Where did I say that? BUt its horses for courses. You wouldn't use assembler
    to write a GUI app even though its possible and you wouldn't use java to
    write a device driver. Why would you use shell to do anything beyond
    process control and basic checking when there are much better alternatives?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kenny McCormack@21:1/5 to All on Sun Sep 17 15:26:50 2023
    XPost: comp.unix.shell

    In article <ue754p$e1uf$1@dont-email.me>, <Muttley@dastardlyhq.com> barfed out:
    ...
    A substitute for interpreted languages such as perl or python. Ie easy to >write with a lot of functionality but slow as hell. If i'd said scripting

    Do you want to explain to this moron that both of the P's he's so fond of
    are, get this, interpreted languages?

    Or do I have to do it?

    --
    Debating creationists on the topic of evolution is rather like trying to
    play chess with a pigeon --- it knocks the pieces over, craps on the
    board, and flies back to its flock to claim victory.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Muttley@dastardlyhq.com@21:1/5 to Kenny McCormack on Sun Sep 17 15:28:41 2023
    XPost: comp.unix.shell

    On Sun, 17 Sep 2023 15:09:53 -0000 (UTC)
    gazelle@shell.xmission.com (Kenny McCormack) wrote:
    In article <ue74ag$dths$1@dont-email.me>, <Muttley@dastardlyhq.com> barfed >out:
    ....
    beyond and way in languages clear doing. yet over writing would who a
    the you leave out shell like of People think the code suggest know wet
    crap then it explains perl any who they years in you what paper I've to a >>python or of hack kind write couldn't by can written is programming their >>code sysadmins. scripting steer they're bag seen lot If I people of of

    Someone just didn't get enough love as a child.

    They say that people like this weren't breast-fed long enough (if at all). >That explains a lot.

    Looks like I scored a bullseye or you wouldn't be so triggered.

    Unfortunately when sys admins write garbage code the dev team in most
    companies often ends up picking up the pieces and usually rewriting it.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kaz Kylheku@21:1/5 to Muttley@dastardlyhq.com on Sun Sep 17 15:58:43 2023
    XPost: comp.unix.shell

    On 2023-09-17, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
    Unfortunately when sys admins write garbage code the dev team in most companies often ends up picking up the pieces and usually rewriting it.

    Alternatively:

    1. Sysadmins are forced to write code around applications that are buggy
    or don't do everything that is required, don't report information
    in good ways, or don't interoperate.

    2. Sysadmins are valuable team members who identify a need, and
    prototype a working solution.

    3. Sysadmins are the only solution providers in companies without a
    "dev team" which is, by my estimation, most companies.

    --
    TXR Programming Language: http://nongnu.org/txr
    Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
    Mastodon: @Kazinator@mstdn.ca
    NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Muttley@dastardlyhq.com@21:1/5 to Kenny McCormack on Mon Sep 18 07:33:35 2023
    XPost: comp.unix.shell

    On Sun, 17 Sep 2023 15:26:50 -0000 (UTC)
    gazelle@shell.xmission.com (Kenny McCormack) wrote:
    In article <ue754p$e1uf$1@dont-email.me>, <Muttley@dastardlyhq.com> barfed >out:
    ....
    A substitute for interpreted languages such as perl or python. Ie easy to >>write with a lot of functionality but slow as hell. If i'd said scripting

    Do you want to explain to this moron that both of the P's he's so fond of >are, get this, interpreted languages?

    Or do I have to do it?

    I would suggest you learn to read basic english first before you accuse others of being a moron.

    Which part of "interpreted languages such as perl or python" confused your lonely brain cell?

    Idiot.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Muttley@dastardlyhq.com@21:1/5 to Kaz Kylheku on Mon Sep 18 07:35:17 2023
    XPost: comp.unix.shell

    On Sun, 17 Sep 2023 15:58:43 -0000 (UTC)
    Kaz Kylheku <864-117-4973@kylheku.com> wrote:
    On 2023-09-17, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
    Unfortunately when sys admins write garbage code the dev team in most
    companies often ends up picking up the pieces and usually rewriting it.

    Alternatively:

    1. Sysadmins are forced to write code around applications that are buggy
    or don't do everything that is required, don't report information
    in good ways, or don't interoperate.

    2. Sysadmins are valuable team members who identify a need, and
    prototype a working solution.

    3. Sysadmins are the only solution providers in companies without a
    "dev team" which is, by my estimation, most companies.

    Yes, that applies to a lot of places. But a lot of places also have sysadmins who right garbage code, get upset when it doesn't work and expect others to
    fix it when they realise they can't. Not a problem when its a scripting language but when they try C or even C++ *shudder*...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Janis Papanagnou@21:1/5 to Muttley@dastardlyhq.com on Mon Sep 18 12:05:29 2023
    XPost: comp.unix.shell

    On 17.09.2023 17:14, Muttley@dastardlyhq.com wrote:
    On Sat, 16 Sep 2023 23:46:04 +0200
    Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
    On 16.09.2023 10:58, Muttley@dastardlyhq.com wrote:
    On Fri, 15 Sep 2023 17:46:39 +0200

    Not perfectly sure I understand the "a substitute interpreted language"
    here correctly. For sure a shell is (and always was; since Bourne) an
    interpreted language. (And David Korn certainly, and correctly, named
    ksh as what it was intended, a "Command and Programming Language".)

    A substitute for interpreted languages such as perl or python. Ie easy to write with a lot of functionality but slow as hell. [...]

    Okay, I see where you're coming from. A few comments...
    The argument should probably be the other way round; perl and python
    (for reasons we may leave alone for the moment) are [maybe] meant as
    substitute for shell (where shells were here earlier as inherent part
    of the Unixes).
    Speed is indeed an issue with shells, though mind; bash is faster than
    old Bourne sh (because of built-in functions that avoid costly external tools/processes), and that Kornshell is a lot faster then bash (as one
    of its central runtime optimization design criteria).


    (This appears to me to be a very limited application view.) - Are you
    saying here that already in 1988 (or 1993 ?) Korn (et al.) provided
    extensions to Bourne sh that were unnecessary? - You think a shell is
    (and should be) just a command line processor (like MS cmd, or so)?
    Even Bourne sh had while/for/case/if/... and signal traps.

    Yes it does, and its as ugly and hacky as fuck with idiotic syntactic
    quirks just like most shells.

    I basically agree on that. Though the control constructs frame of the
    sh-family (the part that was heavily influenced by the [probably most
    formal] Algol[68] language) is still an outstanding clean concept!
    It's amazing that in Unix they invented such a language base for stuff
    that was formerly handled by simple "command processors".
    The ugly stuff, all that cryptic syntax parts, is indeed a "challenge"
    for the programmer. Note here, though, that even that ugly part of the
    shells' syntax has been made to some degree coherent by the Kornshell
    designers (and some made their way into the POSIX sh and other shells).

    No sensible dev uses shell beyond kicking
    something off and maybe simply monitoring. Sysops however whom mostly can't code well to save their lives seem to think programming in shell is normal because often thats all they know.

    (These opinions, prejudices, and generalizations can't be sensibly
    commented on; I abstain. It certainly doesn't [generally] match with
    the various folks that are doing such tasks hereabouts that I've seen.)


    It's really hard to understand (from your statements) your view what
    you think a shell should provide and what it shouldn't. Some examples
    would help.

    Sub shell, co processes, process substitution, lists, idiotic numeric
    syntax with (( )) everywhere (not to be confused with () or [[]] !) and
    make sure you use your whitespace correctly because [hacky historical reasons].

    This is correct. To pick out one prominent example from your list...

    Numeric processing. You wouldn't do math, say, algebra with matrix
    calculations in shell. But you have to handle numbers and numeric
    expressions. That's why (besides the clumsy 'let') the $((...)) has
    been introduced in shell to write readable math expressions inside
    the parenthesis and use its value. The introduction of ((...)) is
    a [syntactically] straightforward ksh extension to use an arithmetic
    expression as command to control the program flow in the Algol-frame
    with a C/C++ boolean logic of arithmetic types.

    Similar with $(...), replacing the old Bourne-sh `...`. It's been
    introduced not only to fix inherent problems with nesting and the
    optical confusion with single quotes and whatnot. The syntax is also
    coherent with the (...) expression. Both forms create sub-processes (conceptually; may be optimized internally to not spawn a process),
    one expands the value for use, the other just runs it.

    So, yes, historic reasons lead to an evolution of shells that lead
    to what we have now. And any language that is designed from scratch
    for specific (other) purposes could be defined with cleaner syntax.
    Though given the syntax of some newer language [versions], say C++,
    current shell versions are not too bad for the areas where we use
    them. (But see also my "beginners" caveat in another post here.)

    [...]
    suited for the tasks I typically do with shell.

    So basically you know essentially squat about real programming yet you're

    (Don't understand what "squat about real programming" is supposed to
    mean.)

    advocating that shell is great for dev. Got it. Reminds me of people who

    (I haven't mentioned "dev" anywhere.)

    only know BASIC and wonder why any other language would ever be needed.

    Well, I cannot speak about "other people" (as you seem to be able,
    as above, here again).

    I can only speak for myself (if that's what helps you understanding
    the area better); I started using shells from the Bourne family on
    a regular basis around 1990. At that time I could fluently program
    software solutions in more than half a dozen high-level programming
    languages from that time (plus a couple assembler). In the following
    decades a couple more languages filled my proficiency list. There was
    never a reason to switch from shell (for the tasks suited for shells)
    to other languages; also later when (e.g.) perl got more mature and I
    used it for (a few) professional tasks [in environments where it was
    possible to use] where it was sensible to use it - it was unnecessary.


    which leads shell authors to bung in features no sane
    person in their right mind would ever need, never mind use.

    Before diving into the details it would be good to know whether you
    are criticizing Martijn's "ksh93 u+m" fixes, or AT&T's ksh93 or ksh88
    and POSIX sh.

    The list posted a few days ago.

    For the second time you didn't answer that question (which was not
    about the list). - From this post I infer that you opinion is to
    not use shell for (which?) tasks. That perl and python are "better".

    That's not much substance. - Good luck, anyway.

    Janis

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Muttley@dastardlyhq.com@21:1/5 to Janis Papanagnou on Mon Sep 18 15:31:33 2023
    XPost: comp.unix.shell

    On Mon, 18 Sep 2023 12:05:29 +0200
    Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
    On 17.09.2023 17:14, Muttley@dastardlyhq.com wrote:
    A substitute for interpreted languages such as perl or python. Ie easy to
    write with a lot of functionality but slow as hell. [...]

    Okay, I see where you're coming from. A few comments...
    The argument should probably be the other way round; perl and python
    (for reasons we may leave alone for the moment) are [maybe] meant as >substitute for shell (where shells were here earlier as inherent part
    of the Unixes).

    Perl yes, though arguably first as an improved awk. Python I don't know. I suspect it was a clean sheet language that he wanted certain functionality in that proved useful as a command line and scripting language too and better
    than Perl for most things.

    The list posted a few days ago.

    For the second time you didn't answer that question (which was not

    I'm not going to repost what he posted. Its easy to find.

    about the list). - From this post I infer that you opinion is to
    not use shell for (which?) tasks. That perl and python are "better".

    They're better for most scripting tasks that require any significant logic and/or mathematics. I'm not claiming they're better for just doing basic unix housekeeping and admin tasks, that would be silly. If you want to do "ls -l" and pipe it to a file obviously you'd use shell. But if you need to go through every file in a directory, sum up some columns in them and print a formatted subtotalling and totalled result you'd at least use awk if not perl/python.
    You sure as hell wouldn't do it all in shell (though you probably could).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)