201–210 of 215 posts
Earlier quoted context omitted.
I think Nu generally plays nicely with other CLI tools and data sources. For example if you've got an external executable that emits JSON, all it takes is `from json` to convert that output to a Nushell table.
It's so wildly awesome to deal with data natively in nushell than donhacky shit with jq and strings... In bash. No thanks.
Earlier quoted context omitted.
That last part is often forgotten. I usually stick with defaults (or as close as I reasonably can) not because they are functionally better but because for most things I don't have the return on learning and regularly using two instances of ${tool} isn't worth the extra time. Sometimes it's a pain but it seems to pay off.
I used to do this, but then found emacs/tramp and that has worked better ever since.
Earlier quoted context omitted.
It is much much better to have things be actual commands (which have a uniform syntax, and are `--help`able) rather than obscure sigils like $(#!@$). Fish is amazing!
Fish is amazing. And. It was missing critical features like subprocesses for so long (10 years?) that I had to keep passing it by. No subprocesses!
There are some old job control bugs, job control behaviors that used to not be POSIX compliant, and one outstanding bug having to do with IO redirection in fish functions that seem like they could be sort of relevant here. But there's nothing I can think of that I could interpret as 'lacking subprocesses'.
I only spent a few minutes looking into this, though. I'm curious to know if you can still recall more specifics, so many years later! Maybe there's something from before I started using fish that I've missed here. But fish is only 18 years old, going by the date of its first release, and I've been using it as a daily driver for ~13 years, and it has had everything I might call 'subprocesses' for that entire duration.
Earlier quoted context omitted.
What if someone starts from a clean slate. Which shell is better? That is the question. Old habits hold us back from progress in usability. Eventually if one system is better it should completely replace the old system. But only if it's better. What one power user deems as "useful" according to his own usage patterns shouldn't be a metric for measurement. I haven't played with nushell yet, but it actually seems more…
From a clean state almost everything is better than Bash. I don't think many people seriously say that Bash is good . We use it because of the insane network effects that come from it being preinstalled almost everywhere (except Windows). The question is not "is nushell better than Bash" - it obviously is. The question is "is nushell better enough that you are willing to install it on every system you use, deal with…
A shell scripting language should also have a sort of convenience that allows the user to easily navigate and manipulate the OS via repl commands. Javascript while definetely a more powerful scripting language lacks the power of a repl OS command prompt.
Bash at the very least has the property of being good as a UI, even though it is clearly a horrible scripting language.
So nushell in this sense unionizes the best aspects of both worlds. Powerful UI, powerful scripting.
Earlier quoted context omitted.
>But most of all the cat way just aligns with my mental model more. Data flows left to right, if you catch my drift. Using ` out_file` (Though annoyingly this doesn't work for feeding input to while loops. `< <(echo a; echo b; echo c;) while read -r foo; do echo "$foo"; done` is invalid syntax; it needs to be `while read -r foo; do echo "$foo"; done < <(echo a; echo b; echo c;)`)
doesn't it work if you put it after the while but before the read?
Earlier quoted context omitted.
Only on Windows. On Linux it's the original `ls`. Same for `cat` and many other commands. That's why using `gci` / `gc` is safer if you want your script to work everywhere. https://learn.microsoft.com/en-us/powershell/scripting/whats...
Aliases can be redefined in certain situations (such as compiling a LCM configuration into a MOF for use with PowerShell DSC). The only safe way to script is to use the full command names (Verb-Noun).
This is fun, but reading the commands[1] reminds me of learning a new language. There are just too of them, and they are all pipelined in a functional manner so I need to understand the I/O of them. In that case, why would one bother remembering all of those, when Xonsh or IPython does similar job to their data, only with a few more lines of (more familiar) code? [1]: https://www.nushell.sh/commands/
I have written a bunch of nu and: no dot method syntax means you need to browse documentation for literally everything. So much worse than your average programming language, which takes the data type + you enter a dot = it suggests all the relevant methods. The Nu docs are better than they were a few years ago but as far as I can tell they keep changing command names, having subtle changes of behaviour for commands w…
Earlier quoted context omitted.
That's bizarre and perverse! Surely someone has brought it up as a bug before that stdin is read-write! Is there some Posix standard preventing the standard shells from opening stdin as read-only???
stdin is readonly. `<a.txt ls /proc/self/fd/0` generally gives 'lr-x------' for the permissions. The problem is that having a open file descriptor to a file lets a program get and/or act-as-if-it-had a path to the file; /proc/self/fd/ is just the easiest way to do that.
There's no reason IMHO to avoid using a file as an argument, or directly as stdin. If you don't trust an app, don't run it in your user account; you run it in a sandbox, right? This is 2023.
Now a case could be made for defending against misbehavior by an app that might write to an fd by mistake, but as a1369209993 demonstrates, writing to stdin is a very deliberate choice, as you'll need to look up a pathname and deliberately open that file as writable. That's not misbehavior, that's malice, and that doesn't belong anywhere near your user account in the first place.
Earlier quoted context omitted.
One of the nice things about bash is that it interacts very nicely with Perl and Ruby. I wonder how these other shells work with the backticks and such in Perl/Ruby. Theoretically there is room for very cool interoperability but I wonder how it goes in practice and if any nice tools and patterns are being developed.
Since this is nushell and perl and ruby are now starting to be considered 'old, is that so much of a problem?