The BASH shell is an inordinate duplicity of features wrapped in a cacophany of syntax, where it's almost impossible to ascertain the sane lowest common denominator and almost-identical appearing syntax can have disastrous results if a single character is missed or added (thus resulting in a completely alternate syntax reality). And when one tries to do something truly elegant, to "master bash", one discovers after weeks of ones irrelevant-to-bash time, that absolutely nothing is elegant, and the variations ultimately make nothing of any even mild complexity/robustness, simple. So then of course one discovers dash, when you want higher performance, a much smaller footprint, or simply to attain that hallowed "lowest common denominator" syntax (don't be fooled friends, don't be fooled!). To test out new code/syntax efficiently one would presume the command line is a reasonable place to go, but for starters dash (at least when launched from a bash shell) has no readline support, and xorg -> xterm -> bash -> tmux -> bash -> dash is evidently too much for little dash, since not even the arrow keys work (nor Home, End, Del and probably others), no readline, no command history, just backspace and paste with the mouse (same on Linux console for the curious...). There goes -that- experiment! Of course there's a certain irony where for increased performance in bash there is the useful-sounding "arithmetic context" feature ("((" and "))"), which by the way is not impelemented in dash - for performance reasons. Oh well, so I throwze in me towell, "eff it! effing eff it already!!" and decides the LCD of "/bin/test" will bring the sanity of consistency if not the salvation of sane syntaxity. But, you guessed it, NO! 'Twas not to be! Dash. Simple. LCD. Yes, that must be it the one true way - I see it in all system scripts - albeit they look a little verbose here and there, there's an undeniable consistency about them, and everyone says "dash runs faster", so it must be true:: performance? check! apparent relative consistency? check! What's not to like? Well, learning the differences for starters. Despite a MUCH more approachable man page than that ungodly bash man page (which is admittedly still better than no man page). And don't get me started on the frustration arising from trying to test dash from the command line due to the frustration of trying to use dash instead of bash in my scripts, due to the frustration arising from the ungodly unconsistencys of bash syntax, and bash syntax as compared with dash syntax, and bash vs dash inbuilt test syntax and vs /bin/test and /bin/[ command line "command" syntax (just try lexico strings comparison with < or > in each environment). AAARRRGHHGHGHGGE !@#@!!.. ... . . . .. ....... . Thy consistency must not be obtained yet ye suffer the inability to compare numbers except for some strange options which evidence the necessity to prefix every test, for numbers or strings, with a bloody x. That's right! The crucifixion of syntax itself with the imposition of the cross, the wholey cross, and nothing but the cross, every where, every time, every place, everywhere, every script, and also every where. And I mean --everywhere-- you look! (Did I mention EVERYwhere?!!). And why? Why thank you for asking - because /bin/test won't work in various system-destroying scenarios otherwise, that's why!!! See above, heathen, see above! <soothing voiceover> Imagine a soft blue light as you experience that quiescence calmly rising, on your deep in-breath, bathed in pure essential shell mastery of that single letter, "x", solving all your syntaxtical perturbxtions, gently smaxhes itxelf on your eye ballx, thux enxuring your enduring peaxe and happinexx with life and Unix itxelf. Seriously, it's time for a change, time for sane shell syntax, time for ... the one true language. (No no! Not the oblig xkcd cartxxn, ANYthing but the oblig!! We need standards, lots of them, and more standards!) And since all the existing shell and scripting standards are completely insufficient, it's time for the obligatory implementation of a new, all-encompassing shell with universal syntax applicable to all languages, all tools and all environments, incestuously binding with all other languages and admitting no deficiency! That's right - you guessed it :) , it's time for Lisp! Shell has had its day, and "eval" is waay too clumsy in comparison with the visual elegance of Lisp where every second letter is an utterly uniform opening or closing bracket, where the original theoretical language struts itself in simple glory and where ultimately every "fancy new design feature" in every "fancy new language" somehow always existed in elegance from the origin. Bow, punk! Bow before Lisp, the alpha and the omega of programming languages! Every concept ever "discovered" in "fancy new programming language"s of the day, from functions to modules, objects to tail calls, run-time self modification, objects, and universal appeal. That's Lisp. Well perhaps that teeny little "universal appeal" bit ... And on that note, a question: Any suggestions as to which functional language variant might be most suitable for "shell" glue script repalement language? Thanks, Z (PS: there's a little rather bland and dull, but nonetheless just mildly humorous, humour, on the fish shell web page: https://fishshell.com/ I might check that out as a bash replacement...)
-------- Original Message -------- On Jul 31, 2017, 5:06 AM, Zenaan Harkness wrote: The BASH shell is an inordinate duplicity of features wrapped in a cacophany of syntax, where it's almost impossible to ascertain the sane lowest common denominator and almost-identical appearing syntax can have disastrous results if a single character is missed or added (thus resulting in a completely alternate syntax reality). And when one tries to do something truly elegant, to "master bash", one discovers after weeks of ones irrelevant-to-bash time, that absolutely nothing is elegant, and the variations ultimately make nothing of any even mild complexity/robustness, simple. So then of course one discovers dash, when you want higher performance, a much smaller footprint, or simply to attain that hallowed "lowest common denominator" syntax (don't be fooled friends, don't be fooled!). To test out new code/syntax efficiently one would presume the command line is a reasonable place to go, but for starters dash (at least when launched from a bash shell) has no readline support, and xorg -> xterm -> bash -> tmux -> bash -> dash is evidently too much for little dash, since not even the arrow keys work (nor Home, End, Del and probably others), no readline, no command history, just backspace and paste with the mouse (same on Linux console for the curious...). There goes -that- experiment! Of course there's a certain irony where for increased performance in bash there is the useful-sounding "arithmetic context" feature ("((" and "))"), which by the way is not impelemented in dash - for performance reasons. Oh well, so I throwze in me towell, "eff it! effing eff it already!!" and decides the LCD of "/bin/test" will bring the sanity of consistency if not the salvation of sane syntaxity. But, you guessed it, NO! 'Twas not to be! Dash. Simple. LCD. Yes, that must be it the one true way - I see it in all system scripts - albeit they look a little verbose here and there, there's an undeniable consistency about them, and everyone says "dash runs faster", so it must be true:: performance? check! apparent relative consistency? check! What's not to like? Well, learning the differences for starters. Despite a MUCH more approachable man page than that ungodly bash man page (which is admittedly still better than no man page). And don't get me started on the frustration arising from trying to test dash from the command line due to the frustration of trying to use dash instead of bash in my scripts, due to the frustration arising from the ungodly unconsistencys of bash syntax, and bash syntax as compared with dash syntax, and bash vs dash inbuilt test syntax and vs /bin/test and /bin/[ command line "command" syntax (just try lexico strings comparison with in each environment). AAARRRGHHGHGHGGE !@#@!!.. ... . . . .. ....... . Thy consistency must not be obtained yet ye suffer the inability to compare numbers except for some strange options which evidence the necessity to prefix every test, for numbers or strings, with a bloody x. That's right! The crucifixion of syntax itself with the imposition of the cross, the wholey cross, and nothing but the cross, every where, every time, every place, everywhere, every script, and also every where. And I mean --everywhere-- you look! (Did I mention EVERYwhere?!!). And why? Why thank you for asking - because /bin/test won't work in various system-destroying scenarios otherwise, that's why!!! See above, heathen, see above! Imagine a soft blue light as you experience that quiescence calmly rising, on your deep in-breath, bathed in pure essential shell mastery of that single letter, "x", solving all your syntaxtical perturbxtions, gently smaxhes itxelf on your eye ballx, thux enxuring your enduring peaxe and happinexx with life and Unix itxelf. Seriously, it's time for a change, time for sane shell syntax, time for ... the one true language. (No no! Not the oblig xkcd cartxxn, ANYthing but the oblig!! We need standards, lots of them, and more standards!) And since all the existing shell and scripting standards are completely insufficient, it's time for the obligatory implementation of a new, all-encompassing shell with universal syntax applicable to all languages, all tools and all environments, incestuously binding with all other languages and admitting no deficiency! That's right - you guessed it :) , it's time for Lisp! Shell has had its day, and "eval" is waay too clumsy in comparison with the visual elegance of Lisp where every second letter is an utterly uniform opening or closing bracket, where the original theoretical language struts itself in simple glory and where ultimately every "fancy new design feature" in every "fancy new language" somehow always existed in elegance from the origin. Bow, punk! Bow before Lisp, the alpha and the omega of programming languages! Every concept ever "discovered" in "fancy new programming language"s of the day, from functions to modules, objects to tail calls, run-time self modification, objects, and universal appeal. That's Lisp. Well perhaps that teeny little "universal appeal" bit ... And on that note, a question: Any suggestions as to which functional language variant might be most suitable for "shell" glue script repalement language? Thanks, Z (PS: there's a little rather bland and dull, but nonetheless just mildly humorous, humour, on the fish shell web page: https://fishshell.com/ I might check that out as a bash replacement...) Get a life ZEN=russian mad man
participants (2)
-
rooty -
Zenaan Harkness