151–160 of 192 posts
Wasn't Hush already the name of the HUmbleSHell ( Hush is a Bourne/POSIX-style shell that was originally part of BusyBox ) ... https://github.com/sheumann/hush
* U-boot: https://github.com/u-boot/u-boot/blob/master/common/cli_hush...
* Busybox: https://github.com/brgl/busybox/blob/master/shell/hush.c
* Barebox: https://github.com/barebox/barebox/blob/master/common/hush.c
Earlier quoted context omitted.
Powershell improves on Unix commands being based on text streams, and makes them based on objects. Which means you're pretty much never extracting stuff with cut and awk, and instead can just get whatever field you want. Eg: C:\Windows> Get-AuthenticodeSignature .\explorer.exe Directory: C:\Windows SignerCertificate Status StatusMessage Path ----------------- ------ ------------- ---- BBD2C438000344F439BFDFE5ABAC3223…
> Isn't that awesome? It depends. In a world where commands produce, expect and consume well defined and highly structured data streams, it is actually great. It works well in Windows but only because scripting as the concept is relatively new to the Windows world. In UNIX, however, it is usually a mess and data extraction using the PowerShell approach would almost never work due spurious characters appearing in the…
Where would they come from?
> (for any reason, really) as the UNIX style is precisely this: «cobble things together, use a sledgehammer to make everything work and move on. If it ain't broken then don't fix it». This is why running the output through a «sed» and searching for stable string patterns to cut interesting parts out and then (optionally) running them through cut/awk/et al is the Swiss army knife.
If you're doing that a lot, the code tends to be fragile. If you use cut for instance, it breaks the second the data you're working it changes. Program decided column needs to be 5 characters wider? Now the stuff you're looking for is not there anymore.
That's how you end up with "ifconfig is old, everyone switch to ip now". At some point a program's output may be parsed by so much stuff that any change risks breaking something, and it forces it to remain static for eternity.
> You can only add stuff easily if you control (own) the producer of the data stream. If the producer is a third party provided script/app you don't have the source code for, I believe you still have the same breakage problem, however PowerShell experts might want to chime in and correct me.
No, my point is that the producer is free to improve without risking the consumers. If your command that produced IPv4 addresses adds support for IPv6, it doesn't suddenly break every script that relies on precise lengths, line numbers and columns.
You can also take somebody else's returned data and add extra stuff to it if you want to, just like you could take a bunch of JSON and modify it.
Earlier quoted context omitted.
The weakness of the shell is that it did not emerge as an LR-parsed language that could easily be expressed with a concise yacc grammar. The "one true awk," for example, bundled a yacc grammar as part of the build until relatively recently. The complex grammar of the POSIX shell is ambiguous in the extreme in many situations. The shell language was further constrained by POSIX that removed much Korn shell functionali…
While being extremely small is a worthy goal, I suppose the aim of Hush is to make writing larger shell scripts easier and less error-prone. It's more for the niche of Perl of old than of minimal shells like ash. For a very limited device, a very limited shell like that in Busybox is sufficient, because it likely does not need large shell scripts, or a lot of interactive work. Looking at [1], current Hush is under 70…
Use on smaller embedded platforms will not be possible. That is the trade.
> Traditional shell scripting languages are notoriously limited I feel like people looking to replace shells and shell languages need to really think deep and hard about this if it's something they believe. Shell scripts are really anything but limited, and in fact most replacements are more limited (either by design or by accident), often imposing awkward control flow on you or making things that should be simple mu…
I've come to the conclusion I can want that all I want, but it's not possible. Shell scripts and interactive usage have too many fundamentally opposing forces in them for one language to bridge the gap. You can be great at one or the other, and you can be bad at both, but you can't be great at both. There simply isn't such a thing, even in theory.
Closest you could get is a language that has two very closely related dialects, but the "dialects" aren't going to be "the same thing, but with a couple of little changes"; there's going to be a lot of differences, enough that people are going to be arguing seriously and with some merit that it's just two languages tied together at the hip.
Earlier quoted context omitted.
> We need better shells. Obviously. I don't think this is the most important missing part, though. I would say it differently: we need way, way better REPLs. IPython is an example of a REPL that's passable as a shell. It can run in a terminal and has a GUI version based on Qt, which allows displaying images inline. You can drop into a "real" shell with a single `!` character (you get pipes, output capture, and (Pytho…
The REPL is the shell. I even used the term "REPL" (and a couple of synonyms too) in my comment. So I do agree it's critical but that doesn't make the language irrelevant. Your point about how Python shells have had to create syntactic sugar for REPl usage is a good illustration of my point about how it matters a lot. Also you can render images in quite a few terminal emulators already. Some shells (mine included) sh…
Of course it matters. The fact that Python is hardly suited for one-liners means that, if you want to write one-liners in it, you'll have to first extend or change its syntax and stdlib, pouring time and effort into creating a DSL for the interactive use-case. Some languages basically are DSLs for one-liners, like AWK, jq, TCL, Perl and Raku; some require minimal effort, like Lisp, Smalltalk, Ruby or Groovy; and some require a lot of work to make the syntax you want work, like Python, Lua, or JavaScript (or Java). So yes, the choice of language definitely matters, but in principle every language with a REPL can be made into a shell with more or less effort.
The problem is that even when you do make that effort, you're stuck with a shell nice for scripting, but with line-editing capabilities of raw readline at best. I would like to see a framework for creating rich REPLs that would be language agnostic, so that I could get a state of the art auto-completion dialog no matter which language I decided to make into a shell.
> Some shells (mine included) ship with hooks to autodetect which terminal emulator you're using and find the best method for rendering those images.
That's an interesting bit of functionality, I will take a look. Thanks!
Earlier quoted context omitted.
> Isn't that awesome? It depends. In a world where commands produce, expect and consume well defined and highly structured data streams, it is actually great. It works well in Windows but only because scripting as the concept is relatively new to the Windows world. In UNIX, however, it is usually a mess and data extraction using the PowerShell approach would almost never work due spurious characters appearing in the…
> In UNIX, however, it is usually a mess and data extraction using the PowerShell approach would almost never work due spurious characters appearing in the output of a command Where would they come from? > (for any reason, really) as the UNIX style is precisely this: «cobble things together, use a sledgehammer to make everything work and move on. If it ain't broken then don't fix it». This is why running the output t…
There are number of ways to prevent that in PowerShell, and by default you usually have to do nothing. But if we imagine that vendor removes some param you relied on in newer versions, you can make it work with old scripts using it by providing so called "proxy function" that returns it back by just adding new stuff on top of existing stuff of underlying function. The similar can be done with objects and properties.
Earlier quoted context omitted.
The REPL is the shell. I even used the term "REPL" (and a couple of synonyms too) in my comment. So I do agree it's critical but that doesn't make the language irrelevant. Your point about how Python shells have had to create syntactic sugar for REPl usage is a good illustration of my point about how it matters a lot. Also you can render images in quite a few terminal emulators already. Some shells (mine included) sh…
REPLs are highly interactive. Shells are also needed to run scripts. A Bourne shell implementation without Readline is a pain to use as a REPL, but is a completely adequate shell scripting tool.
The language looks really quite interesting. I could see myself using it for quick scripts. I think I'd prefer bash's noclobber behaviour to be the default redirection style. The explicitness of being forced to >| always feels like a nice safety feature to me, which would tie in nicely with their other defaults for safer scripting. Also, not sure I'm keen on their minor change to the redirection syntax¹. It suggests…
> It suggests that "2>1" and "2> 1" have very different results FYI, "2>1" and "2 >1" already have very different results in Bourne shell. So I don't think it's an unforgivable sin.
Although making such an error in my example doesn't seem to invalidate my point. It takes an already odd syntax and makes it subtly different, instead of tightening it up.
Earlier quoted context omitted.
> Isn't that awesome? It depends. In a world where commands produce, expect and consume well defined and highly structured data streams, it is actually great. It works well in Windows but only because scripting as the concept is relatively new to the Windows world. In UNIX, however, it is usually a mess and data extraction using the PowerShell approach would almost never work due spurious characters appearing in the…
> In UNIX, however, it is usually a mess and data extraction using the PowerShell approach would almost never work due spurious characters appearing in the output of a command Where would they come from? > (for any reason, really) as the UNIX style is precisely this: «cobble things together, use a sledgehammer to make everything work and move on. If it ain't broken then don't fix it». This is why running the output t…
Logging components being the worst offenders immediately spring to me. Especially the ones that receive data points over a network in heterogenous environments. syslog running on a flavour ABC of UNIX receives an input from a locally running app that has a buffer overrun, the app has previously accepted a longer than permitted input and dumped the actual log entry + all trailing the garbage until the app encountered ASCII NULL into syslog. syslog does not care about the correctness of the received entry and, hence, is not affected and, say, diligently dumps it into a locally stored log file. The log parser is now screwed. I can think of similar examples outside log parsers, too, such interoperability related between different systems.
Granted, it has become less of a problem in recent years due the number of UNIX varieties having gone extinct or languages and frameworks considerably improving in the overall quality, but it has not completely disappered. Just less than a couple of years ago, a sloppy developer was dumping the PDF file content (in binary!) into the log file. The logger survived, but the log parser had a severe case of indigestion.
> If you're doing that a lot, the code tends to be fragile. If you use cut for instance, it breaks the second the data you're working it changes. Program decided column needs to be 5 characters wider? Now the stuff you're looking for is not there anymore.
You are absolutely correct. This is why I do not use «cut» and treat all columns as variable length patterns that can be matched using a regular expression in «sed». It is immune to column width changes as long as the column delimiters are known that are used as start and stop characters. «cut» is only useful when parsing fixed-length formats, such as SWIFT MT940/MT942, where the column width is guaranteed to remain fixed. «cut» is just overcomplicates everything and makes scripts prone to unpleasant breakages.
> That's how you end up with "ifconfig is old, everyone switch to ip now". At some point a program's output may be parsed by so much stuff that any change risks breaking something, and it forces it to remain static for eternity.
The cited reason to switch to «ip» was an unrelated to parsing, if I recall it correctly. But otherwise you are correct, the community has a proven track record of resisting changes in the output format due to the risk of breaking gazillions of cobbled together and band-aided shell scripts.
> No, my point is that the producer is free to improve without risking the consumers.
This is not guaranteed. If the producer changes the content of the structure or merely extends an existing structure, then consumers will continue to consume. However, if the producer decides to changes the structure of the output content itself, the breakage problem still persists. Changes to the content structure not infrequently occur when person A hands over to person B something called a piece XYZ that have been working on before, and person B has a different way of doing the same thing.
> If your command that produced IPv4 addresses adds support for IPv6, it doesn't suddenly break every script that relies on precise lengths, line numbers and columns.
Anything that is tightly coupled with precisely defines things is going to break, there is no scripting solution possible, I am afraid. E.g. if the script author relies on the maximum IPv4 address length (AAA.BBB.CCC.DDD) to never exceeed 15 characters or a specific format of IPv4 addresses, the added suppport for and IPv6 addresses appearing in the output will certainly break the script. Again, one possible solution is to treat all values as variable length patterns that are enclosed within delimiters and do not try to interpet the column content.
> Traditional shell scripting languages are notoriously limited I feel like people looking to replace shells and shell languages need to really think deep and hard about this if it's something they believe. Shell scripts are really anything but limited, and in fact most replacements are more limited (either by design or by accident), often imposing awkward control flow on you or making things that should be simple mu…
I want a shell language that wonderfully encompasses both interactive usage and the creation of easy, safe, effective shell scripts. I've come to the conclusion I can want that all I want, but it's not possible. Shell scripts and interactive usage have too many fundamentally opposing forces in them for one language to bridge the gap. You can be great at one or the other, and you can be bad at both, but you can't be g…
My latest discovery - Raku - does try, and with not bad results. Also, Scala and Ammonite work quite well. Clojure and Babashka, too.
> There simply isn't such a thing, even in theory.
That's a very strong claim. What makes you think it's impossible to design such a language? The fact that none exists currently doesn't mean that it can't exist.
> arguing seriously and with some merit that it's just two languages tied together at the hip.
Just use Racket :-) It's a bundle of tens of languages anyway, so nobody will complain if you add one more. https://rash-lang.org does this. Due to how Racket works, you can write scripts for that shell in anything from Scheme to Typed Racket to Datalog to Brainf*ck (and more, obviously).