[HN Gopher] I want a better shell (2019)
___________________________________________________________________
I want a better shell (2019)
Author : ingve
Score : 77 points
Date : 2021-09-10 13:39 UTC (9 hours ago)
(HTM) web link (matklad.github.io)
(TXT) w3m dump (matklad.github.io)
| tallclair wrote:
| Something that prevents me from adopting a lot of superior modern
| tools is that I need to SSH into a lot of servers and other
| machines that don't have the tools installed. I don't want to
| maintain the muscle memory and knowledge of 2 separate workflows
| & toolchains for the same tasks on different machines.
|
| I'd like to see something that runs locally with my aliases,
| keyboard shortcuts, plugins, etc. and translates the commands to
| a remote backend, maybe similar to VS code's remote development.
| mixmastamyk wrote:
| Something like ansible can synchronize a dev environment on a
| large number of boxes.
| partdavid wrote:
| True. And here is where what people _think_ is a virtue of a
| standard Unix shell (zsh or bash, say) is actually not as good
| as it seems ( "it's already everywhere"); because shells like
| this don't have dependency management, you have to do it all
| yourself. Either out of band (make sure curl and jq is
| installed, which awk is this? oh and all the other little
| things that are buried in my scripts and functions but are not
| declared in a standard way). Now I have a full-on configuration
| management problem that I will need to integrate--just to make
| your shell scripts, snippets and functions work) or by bizarre
| horkiness in your scripts (pure-bash json libs, anyone?).
|
| Interestingly, if all of your machines were to have Powershell
| core, you can actually do a lot of what you describe over SSH
| more elegantly with Powershell remoting.
| ithkuil wrote:
| > When my Rust program panics and prints that it failed in
| my_crate::foo::bar function, I want this to be a hyperlink to the
| source code of the function.
|
| I had some success with good old plan 9 plumber (via the plan9
| from user space distribution for Linux/Mac). You can define
| you're rules for which text to match under which context and it
| can send data to other programs, which can be scripts that talk
| to your editor and translate the clicked text into the right file
| and location to open.
| oscargrouch wrote:
| I think what i'm working with would definitely help in this
| endeavor.
|
| Will let this comment here also as a mark, so i can come back
| latter (2 months from now) and poke the author to see if it does
| what he was intending..
|
| Of course it not the concrete shell, but the platform to build
| such a shell, and anything else (applications in general)
| really..
| NoGravitas wrote:
| This person really just needs to lean into Emacs harder. The real
| strength of Emacs comes when you use it for everything, and so
| have a perfectly consistent, extensible, and discoverable user
| environment.
| satyanash wrote:
| > This person really just needs to lean into Emacs harder.
|
| hehe, +1
|
| leaning into it harder means understanding it better, the
| internals, why it works and why it does things the way it does.
|
| Now only if our phones were lisp machines.
| thom wrote:
| Yeah, a shell is just interacting with a bunch of text, and
| once you've built up some familiarity with Emacs you can reuse
| everything you've learned (search, autocomplete, cut/paste, and
| once you have some elisp skills then basically anything).
|
| One of my annoyances with VSCode, which I do think will one day
| eat the world, is that it still seems the basic level of
| abstraction is too high. So there's a separate terminal window,
| which I always have to tell to go away, and which has its own
| key bindings. What I want is just a text buffer running my
| shell, that behaves like every other text buffer. Same with the
| database clients available for VSCode - stop building UIs, just
| give me text with a process running in the background. The
| editor is already all the UI I need.
| jrm4 wrote:
| This may seem unrelated but I'm going with it; I did Emacs for
| a year or so and while I understood that you CAN go this way, I
| mean, "difficulty in getting there" matters.
|
| "Do everything in Emacs" is an exceedingly short hop from
| "Maybe just write your own operating system."
|
| It's possible to do "very extensible" and "easy to onboard" --
| Obsidian.md is the "actually usable Org-mode" I've been looking
| for, YMMV.
| NoGravitas wrote:
| I'm coming up on using Emacs for 30 years this spring, so
| that's kind of a different experience from using it for a
| year or so.
| kps wrote:
| > ctrl+c, ctrl+v and friends should work as expected.
|
| Right -- I expect Ctrl+C to send SIGINT, and Ctrl+V to take the
| next character literally. I hate it when programs hijack them for
| something else.
| spsesk117 wrote:
| Sometimes it seems like I'm the only person that doesn't feel
| like they need "a better shell". This topic comes up a lot on HN.
|
| Maybe if a better shell came along I'd be surprised, not knowing
| what I was missing. Perhaps I'm just in the dark or not
| imaginative enough to conceive of what one would look like.
|
| With that said, whenever the discussion comes up, it seems to
| revolve around user specific workflow cases and "do what I want
| you to do, not what I tell you to do" design patterns, that would
| (from my perspective at least) feel hard to get right for
| everyone. As a result, we have lots of different shells now that
| make different trade offs and take different design approaches.
| That's great, right?
|
| I don't know -- I'm rambling I suppose, I just don't ever really
| feel like Bash (or fish/zsh/whatever) is holding me back or
| making my work more difficult than it needs to be. We can argue
| about the esotericisms of shell scripting and how it's silly to
| emulate old terminal escape sequences in virtual terminals, but I
| feel like it misses the point.
|
| I don't know, I'm certainly willing to change my mind here, it's
| just that for all of the problems I have day to day in
| sysadmin/programming job functions, the shell is the least of my
| worries most of the time.
| mamcx wrote:
| Well, nearly nobody have experience with a REAL good shell. Is
| like using C all your life and don't have experience what a
| truly good language is.
|
| I work in FoxPro DOS back in the days.
|
| That is another dimension. Was close to jupyter + IDE +
| Database Builder + Form Builder + Code Editor + ... and the
| language to make stuff is NOT a joke.
|
| That is not the only vision that happen in the past but is
| forgotten (or rebuilded with a massive micro-service/over-
| engineer/multi-machine version).
|
| /r
|
| So, to me, using the shell is purely because not exist most
| stubborn people that the one that lives in the unix/c world,
| that have forced for decades the use of the most arcane and
| inferior toolchain possible, and always shutdown any attempts
| of improvements under the excuse "but it works for me".
|
| Is like regulatory capture to 1000x.
|
| /r
| pxc wrote:
| Imo the OP isn't really talking about a better shell in the
| sense that most next-gen shells aim to be. Seems like what
| they're really asking for is newer standards for terminal
| emulation and terminal multiplexing that allow shells to handle
| all the configuration in one place and support better
| integration for web content and probably multimedia. I agree
| with the OP that that would be nice, but I agree with you that
| it seems less urgent than other aspects of my computing
| environment.
|
| This, though, I don't understand:
|
| > We can argue about the esotericisms of shell scripting [...]
| but I feel like it misses the point.
|
| Shells are, among other things, programming languages. How can
| attentiveness to the suitability of that language possibly miss
| the point?
| spsesk117 wrote:
| Thanks for the reply. I think you make a fair point regarding
| shells as programming languages.
|
| I guess what I meant regarding missing the point is that,
| from my perspective, the shell was and is a basic way to
| interface with your computer system. Basic is a keyword here
| -- there are other ways to do it (native programs, syscalls,
| etc), but as a basic interface into operating and running
| programs on a computer, I think most shells do a pretty good
| job.
|
| As I said in my original comment, maybe they could be doing a
| better job and I'm just not seeing it, but this is in essence
| my thought. If Bash is too messy, there are a wealth of other
| highly portable and maintainable languages to do cross
| platform scripting on. Python comes to mind, as does Rust,
| and even older things such as Perl.
|
| I'm rambling a bit, I'm not sure my thoughts on the matter
| are that coherent. I guess in summation I'd just say, I think
| it's fine if shells are shells, and if they can't be
| stretched to accommodate hyper specific workflows and
| patterns, maybe consider writing it another language? Do
| shells languages have to be as capable as general purpose
| programming languages, and if so, why?
| pxc wrote:
| > I'm rambling a bit, I'm not sure my thoughts on the
| matter are that coherent. [...] Do shells languages have to
| be as capable as general purpose programming languages, and
| if so, why?
|
| I think your thoughts here are definitely coherent, and in
| fact you're getting to the heart of the issue. This exact
| question is pretty central in motivating many next-
| generation shells. I'll refer to the documentation of a few
| of them below. Feel free to follow the associated link to
| tug on any of the threads and see if the overall argument
| holds in your opinion. > Python and Ruby
| aren't good shell replacements in general. Shell is a
| domain-specific language for dealing with concurrent
| processes and the file system. Python and Ruby have too
| much abstraction over these concepts, sometimes in the name
| of portability (e.g. to Windows). They hide what's really
| going on.
|
| -- Oil Shell: Why create a new shell?: Shouldn't scripts
| over 100 lines be rewritten in Ruby or Python? (
| https://www.oilshell.org/blog/2021/01/why-a-new-
| shell.html#s... ) > Traditional shells use
| strings for all kinds of data. They can be stored in
| variables, used as function arguments, written to output
| and read from input. Strings are very simple to use, but
| they fall short if your data has an inherent structure. A
| common solution is using pseudo-structures of "each line
| representing a record, and each (whitespace-separated)
| field represents a property", which is fine as long as your
| data do not contain whitespaces. If they do, you will
| quickly run into problems with escaping and quotation and
| find yourself doing black magics with strings. [...] Elvish
| offers first-class support for data structures such as
| lists and maps.
|
| -- Elvish: Some Unique Semantics: Structureful IO:
| Motivation ( https://elv.sh/learn/unique-
| semantics.html#motivation ) > bash does not
| meet any modern expectations for syntax, error handling nor
| has ability to work with structured data (beyond arrays and
| associative arrays which can not be nested). Let it go. You
| are not usually coding in assembly, FORTRAN, C, or C++, do
| you? They just don't match the typical Ops tasks. Don't
| make your life harder than it should be. Let it go. (Let's
| not make it a blanket statement. Use your own judgement
| when to make an exception). > > Python along
| with many other languages are general purpose programming
| languages which were not intended to solve specifically Ops
| problems. The consequence is longer and less readable
| scripts when dealing with files or running external
| programs, which are both pretty common for Ops. For
| example, try to check every status code of every program
| you run, see how your code looks like. Sure you can import
| 3rd party library for that. Is that as convenient as having
| automatic checking by default + list of known programs
| which don't return zero + convenient syntax for
| specifying/overriding expected exit code? I guess not.
|
| -- Next Generation Shell: bash or Python? The Square Pegs
| and a Round Hole Situation: Both are Inadequate for Ops (
| https://ilya-sher.org/2020/10/31/bash-or-python-the-
| square-p... )
|
| For me, the great thing about a shell language is that it's
| a programming language I get to _live_ in. Scripts can just
| grow organically from commands I chain together at my shell
| prompt, including simple loops and blocks and stuff. The
| better I get at the programming language, the better I get
| at navigating my computer and performing routine tasks. The
| better I get at navigating my computer and performing
| routine tasks, the better I get at the programming
| language. This is a really wonderful kind of thing imo, but
| its usefulness is undermined when one dimension of the
| shell (interactivity or programming capability) holds back
| the combination of the two.
|
| The idea with these new shells is to try to find a way to
| enhance the programming capabilities of shells _without_
| making them any less convenient for navigating the
| filesystem and performing simple tasks with external
| programs. There definitely are shells that (imo) have tried
| to improve programmability (usually be embedding in a full-
| fledged programming language) in a way that undermines the
| simplicity and freeform character of shell languages, for
| example Rush (embedded in Ruby), Ammonite (embedded in
| Scala) and Xonsh (embedded in Python.
|
| But other next-generation shells, mostly following the
| examples of PowerShell and Fish (and lots of programming
| languages), (imo) do a remarkable job of improving
| programmability without making simple, everyday shell
| navigation workflows feel any weirder or more laborious. In
| particular, Elvish, Nushell, and Oil Shell strike me as
| very thoughtful efforts whose very small teams of
| contributors have been hacking away at them for quite a
| long time.
|
| One important thing to keep in mind for this particular
| breed of next-gen shells is that their novelty is mostly in
| the well-integrated synthesis of a sizeable collection of
| minor and conservative innovations that we've seen in some
| shells (like PowerShell) and some programming languages
| (especially Lisps) for a long time. Each of these shells is
| a substantial leap forward beyond shells like Bash only
| because the language designs of shells like Bash have been
| largely frozen for decades. For a concrete example of this
| perspective: > Nu takes cues from a lot of
| familiar territory: traditional shells like bash, advanced
| shells like PowerShell, functional programming, systems
| programming, and more. But rather than trying to be the
| jack of all trades, Nu focuses its energy on doing a few
| things well: > > \* Create a flexible cross-
| platform shell with a modern feel > \* Allow you to
| mix and match commandline applications with a shell that
| understands the structure of your data > \* Have
| the level of UX polish that modern CLI apps provide
|
| -- The Nushell Book: Introduction (
| https://www.nushell.sh/book/#introduction )
|
| That phrase at the end of the second bullet point is key:
| 'a shell that understands the structure of your data'. We
| can see a clear call for shells like that in the crop of
| fancy new CLI tools that are designed for chopping up,
| quertying, and formatting 'structured' (not merely textual
| or stringly-typed) data that frequently show up here on HN:
| jq for JSON, yq for YAML, xsv for CSV, etc. Developers want
| to be able to pull in structured data from all kinds of
| sources, query them and manipulate them right there inside
| their shells. But each format gets its own utilities for
| that kind of querying and manipulation, and they don't
| necessarily know how to talk to each other. The pipelines
| we use to plug various tools like this into each other,
| meanwhile, only know about raw text/byte streams. The
| natural thing to want, when you're faced with this, is to
| be able to just ingest data of all of these forms into
| variables in your shell which _retain_ that structure, and
| query them in a uniform way (that your shell may even be
| able to assist you with as you type, with some static
| checking!).
|
| The Elvish shell has a nice example of using this to query
| the latest Elvish issues from GitHub on their website:
| curl -s https://api.github.com/repos/elves/elvish/issues |
| from-json | all (one) | each [issue]{ echo
| $issue[number]: $issue[title] } | head -n 11
|
| which prints, on my system right now: 1396:
| Exception control: "try" should rethrow flow control
| exceptions 1391: Document forking behaviour
| 1385: Feature request: command to find location of rc.elv
| file 1381: `use edit` creates a crash situation for
| elvish 1380: Issues running `wal -i` 1377: exit
| builtin does not trigger program's defer statements
| 1376: buildin cmd source ! 1374: Feed stdin to all
| code blocks in run-parallel 1373: Recent
| performance/speed benchmarks? 1372: Octal Format
| Specifier 1371: "autoview", tables, new data
| formats...
|
| Imo that's pretty neat and concise! Now that JSON is
| increasingly a de facto standard interchange format, not
| just for web apps but often (optionally) for CLI programs,
| I think having idioms like this in your shell makes a ton
| of sense. And we don't have to give up the convenience of a
| simple, fast, convenient, interactive shell experience to
| get it!
| rgoulter wrote:
| Fish shell's joke tagline is "Finally, a command line shell for
| the 90s".
|
| I believe that the developer experience for all sorts of
| tooling has improved dramatically over the last 15 years or so,
| coinciding with GitHub's rise in popularity.
|
| e.g. the plugin ecosystem for Vim or Emacs have improved, let
| alone options like VSCode. Tools like Vagrant made it easier to
| work with VMs. Containerised workflows have similarly improved
| some cases. Languages like Go-lang or Rust seem pretty nice in
| some cases. etc.
|
| Shells are also the kind of thing that developers use. I don't
| believe bash is the best we can practically get. -- Though.. I
| have heard of other, fancier shells; (or cool ideas like
| https://ambrevar.xyz/lisp-repl-shell/ or
| http://howardism.org/Technical/Emacs/literate-devops.html).
| These haven't caught on.
| BeetleB wrote:
| Have you tried magit? Not a serious user myself, but for many,
| many folks it is way better than using git on the command line
| (or via any GUI). When he says he'd like that type of interface
| for all command line utilities (like tar), I can appreciate
| what he's referring to. Much more discoverable than reading man
| pages.
| spsesk117 wrote:
| Thanks for the reply.
|
| I do use magit, daily, and I really enjoy it. I think what I
| don't understand about the OP's point is that, why is that
| the shells problem? Tar is a utility that works great, and is
| typically pretty easy to use on the CLI. If however, I don't
| particularly like it, or would rather use a GUI that's
| totally understandable.
|
| The OP could even implement one in elisp for emacs.
|
| I guess my thought is that, why is the burden on the author
| of this magical new shell to write a piece of software that
| can GUIfy tar, than the user of tar who doesn't like it's
| ergonomics? Maybe that's not what the author is saying, but
| to me it just seems like something not really related to the
| shell, or a discussion on shells.
|
| If you like using GUIs, find a GUI for tar, or write one. I
| don't say that to be flippant, but more to reiterate my
| misunderstanding of how this relates to a discussion on
| shells.
| BeetleB wrote:
| > I think what I don't understand about the OP's point is
| that, why is that the shells problem?
|
| I think to understand his point, substitute "universal text
| interface" with "shell".
|
| What he really is describing is something very Emacs-like,
| but with a better config than you normally find in Emacs.
| He'd like most command line utilities to automatically have
| a magit-like interface through some universal spec/language
| (i.e. so that each utility doesn't have to create the
| interface independently).
|
| Tar is one of those utilities that many people, including
| me, can never remember the options. I can relate to him on
| that one. If I had a magit like interface for tar, I'd be
| really happy.
| mixedCase wrote:
| I'm in the same boat. Even for nontrivial shell scripts just
| having shellcheck around, assuming bash availability everywhere
| and treating `set -euo pipefail` (optionally -x bit too for
| some scripts) as a required header means I'm very happy writing
| and reading shell scripts.
|
| The only thing I've seen after well over a decade of Linux
| usage on desktop and servers that I've thought "this shouldn't
| have been a shell script" was xdg-open. But even then when
| things when wrong I was glad it was a script I could easily
| tweak and debug, at least.
| spicybright wrote:
| Semi related. It's about re-working how processes handle I/O, but
| has some neat terminal UI elements
|
| https://acko.net/blog/on-termkit/
| agambrahma wrote:
| If you squint just right, Sublime Text, or even BBEdit, can serve
| this purpose (i.e. keeping aside Emacs and tmux+neovim for a
| moment)
| MrWiffles wrote:
| Doesn't have all the author's desired features out of the box,
| but recently I was forced into using PowerShell (Core edition,
| which is OSS, different from Windows only pwsh) for a work
| project and you know what? It's surprisingly capable! It's
| available from powershell/powershell on GitHub as a built binary
| for multiple systems and architectures including MacOS and Linux,
| or you could compile it yourself since it's open source. The
| powershell gallery is the marketplace this guy was talking about,
| so there's that. And you can distribute or consume fully
| encapsulated modules as well. The scripting language itself is
| fully object oriented, and while it takes some getting used to,
| you quickly start seeing real value in your day to day from the
| conventions and patterns established by the community over the
| years. I haven't switched entirely from zsh yet, but I'm slowly
| investigating exactly how to do that as time allows. It's a bit
| more verbose than typical Unix shells so you type a little more,
| but that's a small price to pay for everything it brings to the
| table. If you've never tried it (OSS version, aka "core" edition)
| I highly recommend it. WAY easier to learn for first timers than
| bash!
| partdavid wrote:
| I've found that as you learn, the verbosity kind of fades away,
| because you adapt your aliases and patterns to your work
| habits. The small amount of remaining "extra" verbosity that
| remains is very worth it, because it gives you more
| discoverability and more consistent ways of handling data in
| exchange.
|
| I would probably rephrase your statement about object-
| orientation: I don't think Powershell is particularly object-
| oriented, but it integrates nicely with object-oriented .NET.
| What I mean is: when writing extensions to Powershell in
| Powershell, you may use objects incidentally as containers for
| structured data, or occasionally to access details in .NET, but
| you are not creating objects or classes--you're working with
| functions in a straightforward way, and it's easy to make your
| functions behave like (take the same options in the same way
| as) "standard" commands.
|
| I switched (completely) a couple of years ago. The main "use
| case" that is Powershell's sweet spot for me is handling
| structured data. A lot of my operations have steps like:
|
| Do some data-wrangling to calculate a URL and request options
| for some data repository or integrated system API; Perform a
| network call or look something up in a big file of structured
| data; Munge and wrangle that data to extract information or
| calculate summaries; Perform more network calls based on that
| data and do further munging and calculating.
|
| This is usually discovery-oriented, interactive, ad-hoc
| lightweight integration, and it's in an environment where I'm
| _doing_ something with this data (like figuring out a machine
| list from a couple of CMDBs, cross-referencing that with data
| from the monitoring system and maybe some lookups for system
| roles, and then performing commands on them). It 's not a great
| fit for a "real" scripting language because the stuff about
| processing the data and doing the network calls is intermixed
| with lots of stuff that the "real" scripting language is not
| very good at, like interactively discovering what's in the
| data, invoking a bunch of OS commands and putting things
| together left-to-right in a pipeline you craft gradually. As
| your activity matures (you find yourself doing the same thing
| over and over), you can start factoring your code into reusable
| units, but not all of it, and Powershell is just super
| excellent at tasks at this boundary, because it's just fine as
| a programming language in its own right (much more capable than
| bash, and with goodies that you reference, like having
| dependency management) while being at least as good an
| interactive shell as bash.
|
| As a "Unix guy", I favor a lot of Unix-isms so of course I
| customize my shell heavily. I can do more powerful things in my
| prompt much more easily than with bash. I like the more
| familiar bash-style tab-completion than Powershell's, so I use
| the PSReadLine module settings to enable that. I use vi keys
| for command-line editing (with remapped cursor motion keys) and
| getting this done is easier to accomplish than doing so in
| bash. I don't like some of Powershell core's default aliases
| (like curl--I want curl to invoke the curl command, and I'll
| use iwr instead of curl when I want Invoke-WebRequest), so I
| disable them.
|
| I do all of my professional work on MacOS and Linux and
| Powershell is a good shell on both, and almost all of my
| experience with Powershell is as a Unix shell. I'm not much of
| a fan of commitment to the so-called "Unix philosophy", but I
| do think that Powershell reflects this philosophy better than a
| typical Unix shell and Unix commands. For example, once you
| learn how to sort the output of ls according to its standard
| options, all you've learned is something about the ls command.
| It doesn't help you in sorting a process list from ps. It also
| doesn't help you in sorting files by something other than size
| (-S), mtime (-t), atime (-u sort of), "natural version in the
| name (what?)" (-v), or alphabetically by extension (-X).
| According to the "Unix philosophy" what is the ls command even
| doing parsing and sorting version numbers anyway? In
| Powershell, it's more natural to let Sort-Object sort things,
| which it can do by any of the item's fields, not just what the
| ls author provided an option for; and once you know you can do
| that, you can do it for processes in just the same way, or AWS
| instances or anything else. Boom. Unix philosophy. (And if you
| just like using ls, and piping it to sort, that works fine,
| too, so no custom is imposed on you). It's kind of beautiful.
|
| Our views on what we want out of a shell are always based on
| the tasks we personally try to accomplish with it, and I don't
| think the author wants a "better shell" at all, but a better,
| more scriptable IDE. His "use cases" for the shell are all
| elementary file management and command invocation and he
| doesn't really seem clear on which component of his system the
| shell actually even _is_. Interestingly, there _is_ a full TUI
| framework for Powershell and it 's pretty cute! I didn't know
| about it before looking it up after reading this article.
| Jenk wrote:
| I still find it grating with how pipes are handled.
|
| E.g. git ls-files --exclude-standard -o |
| For-Each { Remove-Item $_ }
|
| Just.. _why_ do I need that For-Each?!
|
| (Deliberately not using aliases for clarity)
| tyingq wrote:
| As far as I can tell, you don't need it if you're piping the
| right stuff to Remove-Item C:\temp\foo> dir
| Directory: C:\temp\foo Mode
| LastWriteTime Length Name ----
| ------------- ------ ---- -a----
| 9/10/2021 1:03 PM 0 thing1 -a----
| 9/10/2021 1:03 PM 0 thing2 -a----
| 9/10/2021 1:03 PM 0 thing3
| C:\temp\foo> dir thing* | Remove-Item C:\temp\foo> dir
| C:\temp\foo>
| Jenk wrote:
| dir works because it's actually an alias of Get-ChildItem,
| which returns a list of objects (DirectoryInfo or
| FileInfo). My example was specifically a list of paths that
| are not objects but just strings.
| tyingq wrote:
| Okay. How about "echo"? (Aliased to Write-Output, which I
| assume is strings) C:\temp> dir file3
| Directory: C:\temp Mode
| LastWriteTime Length Name ----
| ------------- ------ ---- -a----
| 9/10/2021 1:03 PM 0 file3
| C:\temp> echo "file3" | Remove-Item C:\temp> dir
| file3 dir : Cannot find path 'C:\temp\file3'
| because it does not exist.
|
| Edit: I see it now. It works with one string, but if I
| Write-Output "file1`r`nfile2" | Remove-Item it no longer
| works because it takes the whole string as an object. I'd
| have to pipe an array of strings rather than cr-lf
| separated strings.
|
| This does work: C:\temp>
| $foo="file1`r`nfile2" C:\temp> $foo -split '\r?\n'
| | Remove-Item
| Jenk wrote:
| Yeah, another one I haven't worked out yet is opening
| mulitple files from shell. So far this is what I can come
| up with: @(Get-ChildItem *.ts | foreach
| { $_.Name } | Join-String -Separator ' ') | foreach {
| nvim -- $_ }
|
| But even that abomnination doesn't quite work.
| [deleted]
| yoyohello13 wrote:
| I've recently been thrust into using PowerShell at work too,
| and it's fine. I still wouldn't choose it, given the option. I
| get why people like the object orient nature of it, but I also
| don't think I get much value from it. 9 times out of 10, if I
| need a shell script, it's just stringing commands together. If
| I'm doing something complex enough to really benefit from
| "everything is and object" then why not just use a more capable
| language like python?
|
| There is a trend of people making increasingly complex and
| expressive shell languages, but I don't really understand what
| problem they are trying to solve. Maybe what we really need is
| a less complex shell so people are less tempted to write
| complex logic with it.
| simion314 wrote:
| I did not use powersehll but recently I was using a CLI
| program that was outputting in a tabular format but it was
| not something well defined that I could easily (with my very
| limited shell experience) parse. Maybe it was the program
| fault that it did not offer some CSV output format or maybe
| there is a natural way of handeling it but is hard to google
| for it.
| pjmlp wrote:
| It is builds up on top of Xerox PARC ideas regarding REPL and
| OS integration.
|
| UNIX systems could offer similar integration, via IPC
| mechanisms, KParts and DBus like communication, exposing shared
| libraries directly into the shell and structured data.
|
| Where it fails down is lack of standardization across the
| landscape, so that everything actually works together.
| kukx wrote:
| One thing about PowerShell that annoys me is the verbosity and
| the use of capital letters in commands. While it is fine for
| scripts that you write once it feels suboptimal for daily use
| in a terminal, where I prefer the least strokes possible. Also
| the slow startup makes me often choose an alternative shell in
| Windows (CMD,bash).
| thibran wrote:
| Did you try out Nushell, what do you think about it in
| comparison to PowerShell?
| pxc wrote:
| Fish has taught me that I should strongly prefer shells with
| batteries included when it comes to interactivity, and Elvish
| has beautifully demonstrated how that can be taken even further
| with things like its built-in navigation mode. PowerShell's big
| weakness, imo, is that it lacks that emphasis on interactivity
| OOTB, and configuring it back in often results in astonishingly
| bad performance.
|
| That said, the language is way better than any traditional Unix
| shell, and the ecosystem of libraries and scripts is insanely
| comprehensive. Together, these factors make for an absolutely
| top-notch scripting experience.
|
| This is definitely one of the the biggest sources of
| inspiration for most next-gen Unix shells afaict.
| 0xCMP wrote:
| I've felt for a long time that we need a better Shell, but I
| think the next evolution is combining the Terminal and Shell
| together.
|
| I've never thought that what was good about the command line was
| that a terminal and shell are different. That's just an accident
| of history. In fact, this feels like a huge area where it's
| inferior.
|
| I don't actually know anyone who uses plain TTYs for their Shell.
| If you use a shell today it's 99% running inside of
| [iTerm2,terminal.app,Gnome Shell,uxrvt,alacritty,etc] on top of a
| window system. It feels obvious to me that instead of trying to
| emulate a hardware terminal from the 70s we should be building
| what is good about that interface into a GUI which makes managing
| processes, their outputs, and crafting the commands easier.
| Intelligent IDE-type auto complete, powerful history, collapsing
| large program outputs, smooth scrolling of the session, Tmux-
| style session management, built-in file browsing and previewing,
| dynamic/reactive prompts and status indicators.
|
| Except for Warp this feels like something few, if anyone, ever
| really considered. I often wonder why.
| SkyMarshal wrote:
| Sounds like what notty was trying to do, though it seems
| unmaintained for 5yrs.
|
| https://github.com/withoutboats/notty/
| jolmg wrote:
| > I've never thought that what was good about the command line
| was that a terminal and shell are different... I don't actually
| know anyone who uses plain TTYs for their Shell. If you use a
| shell today it's 99% running inside of
| [iTerm2,terminal.app,Gnome Shell,uxrvt,alacritty,etc] on top of
| a window system.
|
| Interactive shells can be used without opening a graphical
| terminal. Simple examples are calling :shell from vim, or S in
| the `ranger` file manager, or entering a docker container, or
| using ssh.
|
| Terminals can also be used without a shell. For example, I have
| keybindings for opening a terminal with a file manager, or with
| vim, or with vim with the clipboard contents and special vim
| keybindings to handle it, or with nothing on it (a process that
| sends a stop signal to itself). This last one is to get a new
| unused terminal window to which I can redirect stuff. For
| example, with `gdb -tty` I can interact with a program from one
| terminal, while having another terminal control it with gdb.
|
| They really are 2 separate types of programs that are useful on
| their own, and their separation allows for more flexible
| handling, like how separate programs can take control of the
| terminal at separate times, like how it happens with vim's
| :shell, etc.
| buescher wrote:
| Every so often I yearn for something that would be like a fusion
| of 4DOS/4NT/Take Command (https://prog21.dadgum.com/74.html), a
| lisp "listener" (https://common-
| lisp.net/project/mcclim/excite.html) and a nicely pre-customized
| unix shell and terminal. Ideally something that could be also set
| up on a windows box without spending a day installing unix-style
| tools.
|
| I'd settle for a nicely pre-customized unix shell and terminal -
| what are the cool kids using these days? fish?
| eatonphil wrote:
| I want a better shell but only in that I want a Bash-like
| language (with builtin Linux userland programs like mv, cp, etc.)
| that works across macOS, Linux, and Windows. (I cannot reliably
| get Bash for Windows installed on every Windows device I own.)
|
| I want this for cross-platform build scripts. I build a desktop
| app for Windows, mac and Linux. I don't want a different set of
| scripts in a different language for each platform.
|
| And I don't want to write in Python or JavaScript or Ruby or Perl
| because they're all so much more verbose than Bash.
|
| But Bash on its own isn't enough either. I need the same Linux
| userland commands to work the same way on Windows. Powershell has
| mv and cp but they don't work the same way or have the same
| flags.
|
| I hacked together a version of this language in Python that
| operates line by line and massages the differences between things
| like mv and environment variables in Windows, macOS, Linux.
|
| https://github.com/multiprocessio/datastation/blob/master/sc...
|
| Here's a sample script it can run: yarn
| setenv UI_ESBUILD_ARGS "--minify" yarn build-ui
| prepend "window.DS_CONFIG_VERSION='{arg0}';" build/ui.js
| yarn build-desktop prepend
| "global.DS_CONFIG_VERSION='{arg0}';" build/desktop.js
| yarn electron-packager --overwrite --out=releases --build-
| version={arg0} --app-version={arg0} . "DataStation Community
| Edition" zip -r releases/{os}-{arch}-{arg0}.zip
| "releases/DataStation Community Edition-{os}-{arch}"
|
| But this is a massive hack. So I'm starting work on a real
| language that supports a reasonable subset of Bash on Windows,
| macOS, and Linux and brings a reimplementation of the few key
| Linux userland commands (mv, cp, mkdir, rm plus new programs like
| append, prepend, replace, etc.) built into the interpreter.
|
| A sketch of this more real version implemented in Go is here:
| https://github.com/multiprocessio/crosh. It doesn't build at all
| yet but if you're interested you can follow along.
| shagmin wrote:
| Have you tried installing WSL2 and using a shell through that?
| Granted if Bash won't run on a machine reliably, WSL2 may not
| do much better on the same machine.
| eatonphil wrote:
| Yeah exactly. I cannot reliably get either WSL(1/2) or Bash
| for Windows installed on every device I own. It worked
| seamlessly on half of them and I can't figure out anything
| about why the others don't work at all.
| mixmastamyk wrote:
| What does this mean? Maybe the cpu is old and doesn't
| support virtualization? Hard to know without details.
| AnIdiotOnTheNet wrote:
| You're not the first, nor do I expect you'll be the last, to
| reinvent the build scripting wheel. Things like this are why
| languages like Zig have decided that the build script language
| should just be the same as the actual programming language.
| eatonphil wrote:
| To be honest, just implementing bash as an educational
| project has been on my list for a while.
|
| Doing a cross platform subset is an even nice combo of learn
| something and keep my build scripts bash-y.
|
| Like I said I really don't want to make these scripts more
| verbose than bash and any other language would mean doing
| that.
| tnzm wrote:
| This is also why I advocate for JS as a scripting language
| (if it's already a part of your stack, anyway). Curiously,
| every time I mention it HN gets mad at me.
| rzzzt wrote:
| This port of busybox might also suit your needs:
| https://github.com/rmyorston/busybox-w32
| handrous wrote:
| Truly, distributing more-than-trivial scripts (if trivial, just
| duplicate effort and have multiple scripts) cross-platform--
| _including Windows_ --and to machines you aren't remote-
| adminning to fit your exact specs is hell, especially if some
| of the users aren't developers.
| eatonphil wrote:
| The use case is _build scripts_ for developer machines and
| automated builds. WSL2 is supported on Github Actions which
| is great. I'm the sole developer but again I just need these
| scripts to work across Windows and the other devices I need
| to test/develop on.
| BeetleB wrote:
| Have you tried xonsh?
|
| It's cross platform, and while the language is Python, it is a
| modified Python so it's not nearly as verbose. You can write
| stuff like "cd directory" in your Xonsh script, as well as
| capture output of commands - No need to import os, shutil,
| subprocess, etc.
|
| Been using it for a number of years. Really happy with it.
| BeetleB wrote:
| Regarding Emacs and this:
|
| > It doesn't define out-of-process plugin API (things like
| hyperlinking output).
|
| The author may want to check out the GNU Hyperbole package.[1]
| I'm not a user, but those who can get through the strange docs
| and UI absolutely swear by it.
|
| [1] https://www.gnu.org/software/hyperbole/
| inshadows wrote:
| Better shell should support pointer devices/events. It's shame
| that you can't move cursor by mouse in Unix shell. There are some
| hacks in Zsh but I haven't yet found enough courage to explore
| it. This is one thing that Command Prompt and PowerShell in
| Windows can do. :)
| iKlsR wrote:
| I'm sure this exists in some form somewhere but something I
| really want is a way to pull up my command history numbered with
| a shortcut and then punch that number to run the last command
| than mindlessly hitting the up arrow for several seconds (why do
| we do this?). If anyone knows anything that has this
| functionality please share, thanks.
| cyberbanjo wrote:
| !10 Runs tenth last command
| iKlsR wrote:
| Yes and there is also Ctrl+R which kicks off a recursive
| search which is what I use most of the time but what about
| the complex 2 liner with pipes and dates 19 commands ago? :)
| [deleted]
| nixpulvis wrote:
| A lot of this has to do with the integration between the Terminal
| and the Shell. A project that came up recently that seems to take
| on a few of the issues is https://blog.warp.dev/how-warp-works.
| I've been meaning to write up a proper critique of this project
| at some point, but I keep getting side-tracked.
|
| I also want a replacement for `fish`, however it's a pretty tall
| order to implement what I have in mind, and I got a bit stuck
| trying to find the right abstractions for background job
| management in Rust (there's a lot going on). But I genuinely
| believe a multi-language shell with POSIX support will finally
| allow us to move forward in the terminal environment. UI/UX
| issues like ctrl-c, window management, and everything else can be
| implemented as derivations from POSIX, or additions.
|
| While somewhat tangential to the main thread of this post, I'll
| still leave my (incomplete) shell here for anyone who's
| interested. https://github.com/nixpulvis/oursh. The README has a
| decent description of features I want off the bat, and there's a
| bunch of design level issues in the tracker.
|
| I'll never accept the death of the Terminal environment.
| haolez wrote:
| Found in Warp's landing page:
|
| "Private - All cloud features are opt-in. Data is encrypted at
| rest."
|
| Wait... was this even under question? Why would my terminal not
| be private? :/
| nixpulvis wrote:
| Yea, that was issue #1.
| wffurr wrote:
| Because it has cloud features:
|
| "#6: Leverage the cloud. The basics of computing have changed
| since the advent of the CLI, and no change has been more
| profound than the rise of the internet. Once you start to
| think about it, there are a lot of leverage points: why is
| shell history limited by your local hard-drive? Why doesn't
| your shell configuration follow you across machines? Why
| can't you transfer a CLI session to the browser so you can
| keep working on the go? (Don't worry, though, Warp is local-
| first, and all cloud features will be opt-in. You can find
| out more in our privacy policy)."
|
| https://blog.warp.dev/how-we-design-warp-our-product-
| philoso...
| nixpulvis wrote:
| File sync is pretty separate from the shell IMO, unless
| your shell is an OS, which can be argued for I guess, but I
| wouldn't.
| abnercoimbre wrote:
| > I've been meaning to write up a proper critique of this
| project at some point, but I keep getting side-tracked.
|
| Plug - I'd also keep tabs on my project, Terminal Click [0].
| It's exploring the relationship between the emulator and the
| shell.
|
| Nushell [1] and I are talking about possible integrations
| between the two products.
|
| [0] https://media.handmade-seattle.com/terminal-click
|
| [1] https://www.nushell.sh/
| hnlmorg wrote:
| Shameless plug but this is exactly what I'm working with my shell
| https://github.com/lmorg/murex
|
| It's designed to work with JSON, YAML, CSV, etc so you don't need
| to remember jq syntax for JSON, awk for CSV, something else for
| S-Expressions and so on and so forth. It's the same commands
| (like grep) that work with all formats and are aware of the
| format.
|
| It can work with tmux to give do stuff like if you hit `F1` it
| will open up a pane to the right with the man page of the command
| you're typing. So it's been built around taking UI lessons from
| IDEs.
|
| But above all else, it's a $SHELL so it works find with all your
| existing CLI core utils. Which is more than can be said for the
| likes of Powershell.
|
| There is a learning curve though because it's not POSIX syntax.
| I've tried to keep some POSIX-isms where they've made sense but
| redesigned things where POSIX was a little counter-intuitive
| (though that's a subjective opinion).
|
| I've been using it as my primary shell for about 4 years now.
| partdavid wrote:
| That looks like a neat project! Nice.
|
| > But above all else, it's a $SHELL so it works find with all
| your existing CLI core utils. Which is more than can be said
| for the likes of Powershell.
|
| Can you expand on what you mean by this? I've been using
| Powershell as my primary shell for 2-3 years and this statement
| surprises me. There's no "core util" I can invoke that behaves
| differently or surprisingly in Powershell so I probably don't
| understand what you mean.
| hnlmorg wrote:
| Maybe I'm wrong on this point then but the few times I've
| tried to Powershell in the past I had issues piping commands
| together because some commands expected text while others
| expected a .NET object and it all felt terribly like working
| in Delphi again with the type system actively working against
| you (I'm exaggerating a little here, love Pascal, but
| hopefully you get my point).
|
| Don't get me wrong, I love strongly typed languages. But when
| you're using the CLI you want a language that is optimised
| for ease and working with CLI tools and Powershell functions
| wasn't easy.
|
| But as I said, I might have been doing something wrong. And
| if that's the case I'll make sure I don't repeat that comment
| in the future :)
| partdavid wrote:
| Out of the box, Powershell comes with some aliases matching
| standard commands, like ls is an alias for Get-ChildItem. I
| think the intention is to make it more 'familiar' for Unix
| users on the "home" platform, where you don't usually have
| native Unix commands, but I found they just got in the way
| and I removed them (aliases like gci for Get-ChildItem
| still remain, so you don't need an ugly verbose command
| line, but you do need to learn some new commands). I'll
| eager that some of your experience was due to these
| aliases, which just get in the way trying to use it as a
| Unix shell.
|
| So far I've actually been surprised at how infrequently
| I've encountered the problem you describe. I don't doubt
| that it's a real problem, but I've generally been pretty
| impressed with how well a list of lines, which come across
| a pipeline as an array of strings, mingles with objects. It
| could be that our "daily driver" tasks have different
| domains so this mismatch surfaces much more frequently for
| what you need to do.
|
| I've had ideas for better shells for decades, mostly around
| handling structured data and easy network connections
| without destroying too much of what makes a shell a shell.
| So genuinely, respect for actually implementing along this
| path.
| zz865 wrote:
| I find the current shell world obsolete. grep/pipes/sed/awk are
| byzantine. Most REPL environments are better. I'd like a terminal
| to go straight to Python REPL and run just Python commands. Would
| be much simpler.
| cyberbanjo wrote:
| Many things requested are available in emacs.
|
| > However, I personally don't use this capability of shell a lot:
| 90% of commands I enter are simpler than some `cmd | rg pattern`.
| > (kbd "C-c") doesn't work as it works in every other
| application.
|
| So rebind it? Even terminal emulators allow for rebinding of
| keybindings, and so does emacs.
|
| > I launch GUI version of Emacs: the terminal one changes some
| keybindings, which is confusing to me. For example, I have splits
| inside emacs, and inside my terminal as well, and I just get
| confused as to which shortcut I should use.
|
| IMHE the solution is to decide which tiling manager you wish to
| you use (my experience is informed by using i3 to tile and
| sometimes emacs). 99% times I use my i3 to tile, and emacs only
| splits in half (C-x 2 or C-x 3 depending on what I need and how
| wide the emacs window is)
|
| > Why can't I type cargo test, Enter, exa -l, Enter and have this
| program to automatically create the split?
|
| What you are looking for is `cargo test &`, `fg`, `bg`, and (kbd
| "C-z"), no? The ability to suspend and bring to foreground or
| background enables this kind of 1. run tests 2. list files. My
| own experience suggest that how I create the split is dependent
| on some, potentially implicit, context.
|
| > Additionally, while magit awesome, I want an option to use such
| interface for all my utilities. Like, for tar?
|
| Firmly agree, and I believe this is what the transient[1] package
| is for.
|
| > extensible application container, a-la Emacs or Eclipse, but
| focused for a shell use-case
|
| Emacs /is/ focused for shell-use case, at least in my
| understanding and use of it.
|
| > A UI framework for text-based UIs, using magit as a model.
|
| ctrl+c, ctrl+v and friends should work as expected. cua-mode
| enables the "normal" copy and paste bindings.
|
| > A tilling frame management, again, like the one in Emacs (and
| golden-ratio should be default).
|
| What's wrong with `C-x 1`, `C-x 2`, `C-x 3`?
|
| > A prompt, which is always available, and smartly (without
| blocking, splitting screen if necessary) spawns new processlets.
|
| Isn't this what M-x is or would it taking up the bottom line
| disqualify it for "splitting". Regarding blocking, I do agree
| it's very annoying to have emacs become unresponsive.
|
| > An API to let processlets interact with text UI.
|
| I would assume that there is something lacking from emacs lisp
| api[2] for manipulating emacs, but it's not clear what they are
| from this authors perspective.
|
| > A plugin marketplace (versions, dependencies, lockfile,
| backwards compatibility).
|
| What is wrong with melpa, quelpa, emacs-wiki, et al?
|
| > It doesn't define out-of-process plugin API (things like
| hyperlinking output).
|
| It sounds like that would require the out-of-process layer
| (shell) to be as expressive as the in process layer. For
| instance, emacs can link to files, and new custom link styles,
| but my terminal is loathe to support http(s)/(s)ftp, and I
| presume is not easily extensible (as emacs) to new protocols.
|
| > Its main focus is text editing.
|
| Everything already communicates in text, it's not clear there is
| a obvious alternative or what would suceed text editing for this
| use-case.
|
| > Its defaults are not really great (fish shell is a great
| project to learn from here).
|
| Perhaps, but the gnu emacs community seem to profess a "we-came-
| first" mentality for conflicts with emacs defaults and the 'wider
| computing experience'.
|
| > ctrl+c, ctrl+v do not work by default, M-x is not really
| remappable.
|
| cua-mode and false, I have m-x remaped to use helm.
|
| 1: https://github.com/magit/transient 2:
| https://www.gnu.org/software/emacs/manual/html_mono/elisp.ht...
| BeetleB wrote:
| > (my experience is informed by using i3 to tile and sometimes
| emacs)
|
| He needs a cross platform solution.
|
| Also, magit is _horrible_ in Windows.
| AtlasBarfed wrote:
| Can I get a parseable ls?
|
| Can I get explicit output-as-json flags for all reasonable
| commands like ps, lsblk, ls, find, grep, etc?
|
| Can I get a database of commands better than history that shows
| when they were run and error codes that resulted AND THE OUTPUT,
| and if it completed for multithreaded/background/etc.
|
| The history-as-database is ultra-important for doing cli
| multiprocessing/async. Fire off command, and then you can get the
| output from the database to pipe to another command.
|
| Can I get a reasonable metashell standard across all terminal
| apps for doing a lot of what .profile does but isn't tied to a
| specific file on a specific machine?
| AtlasBarfed wrote:
| I'll expand this more. What I really want and have already
| partially built for some things is a very powerful metashell
| for delivering commands across multiple machines and composing
| them.
|
| As referenced above, a central database of command, exec
| status, output, and where executed would be central to this.
|
| THe ability to define sets of machines as clusters and running
| and returning commands from those in parallel is also essential
|
| The ability to pull, push, edit files remotely...
|
| The ability to store access methods to deliver and return the
| commands: be it ssh, teleport, (ugh) telnet, kubectl, docker
| run, aws ssm, etc.
|
| I've written about 20% of that for my current job managing
| various nosql database clusters. But it is very much ugly and
| something I'm very far from being happy with, even after about
| two rewrites
| nathanmcrae wrote:
| You may have already seen it but jc
| (https://kellyjonbrazil.github.io/jc/) helps with the first
| two: $ jc ls -l | jq [ {
| "filename": "bin", "flags": "drwxr-xr-x",
| "links": 1, "owner": "nathanmcrae",
| "group": "nathanmcrae", "size": 4096,
| "date": "Jun 28 15:15" }, {
| "filename": "pkg", "flags": "drwxr-xr-x",
| "links": 1, "owner": "nathanmcrae",
| "group": "nathanmcrae", "size": 4096,
| "date": "Jun 28 15:15" } ]
| enriquto wrote:
| This is horrifying! Why would anybody want that?
| AtlasBarfed wrote:
| ... because you want something that jq can reliably parse
| from the filesystem listing output?
| partdavid wrote:
| I think Powershell gets you part of the way down this road, at
| least on some of these features, without requiring you to
| figure out everything/adopt everything first. Out of the box it
| works fine as a Unix shell (you know, invokes commands, pipes
| output, etc.).
|
| Everything's not rosy-hunky-dory, each of these have
| limitations but:
|
| > Can I get a parseable ls?
|
| > Can I get explicit output-as-json flags for all reasonable
| commands like ps, lsblk, ls, find, grep, etc?
|
| Better than "parseable", you get commands which just return the
| structured data, for ls (gci), and many other "foundation"
| commands like ps (gps), etc. I didn't actually think about a
| structured grep but maybe you wouldn't use it as much with
| stuff like ConvertFrom-Csv (so you have structured data to
| select rather than strings to "grep"). Anything you _can_ get
| JSON or YAML or CSV output from you can just turn into
| structured data (ConvertFrom-Json) and handle in the same way.
| Any native Powershell implementation of anything will emit
| complex data in the same way (e.g. AWS 's Powershell tools).
|
| > Can I get a database of commands better than history that
| shows when they were run and error codes that resulted AND THE
| OUTPUT, and if it completed for multithreaded/background/etc.
|
| Background job handling is a lot better with Powershell than
| with bash and allows you to address background jobs by id, get
| metadata about them and the output, with rcjb (Receive-Job).
| Your job list is manipulatable with the same Powershell tools
| as everything else, so you can sort and select easily on things
| like status or the host on which it executed.
|
| > Can I get a reasonable metashell standard across all terminal
| apps for doing a lot of what .profile does but isn't tied to a
| specific file on a specific machine?
|
| It's an interesting idea, hard for me to conceive. Do you mean
| shell and command configurations that go along with your shell
| session to other machines? Powershell remoting allows you to
| establish a session and then mix local and remote commands
| while retaining your setup and environment, it may partly help.
| The gotcha: you need to enable the SSH configuration which
| allows this and (of course) have Powershell installed on the
| target systems.
___________________________________________________________________
(page generated 2021-09-10 23:01 UTC)