[HN Gopher] GitHub - nushell/nushell: A new type of shell
___________________________________________________________________
GitHub - nushell/nushell: A new type of shell
Author : axiomdata316
Score : 701 points
Date : 2021-06-16 04:48 UTC (18 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| kayman wrote:
| Similar to "bourne shell" and "bourne again shell" aka bash
|
| I can see the evolution now. "nushell". Next iteration: "nuer
| shell" (newer) or "renushell" (renew)
| rdudekul wrote:
| Here is a recent video on Nushell 0.32 features:
| https://www.youtube.com/watch?v=AqYxhJKblvY
| larodi wrote:
| there's fair amount of comments here (and in other similar posts)
| which read like:
|
| 'nushell is basically a powershell something' 'bash/zsh is
| better/worse than pwsh/etcshell'
|
| this is very unfair because pwsh allows control over of the all
| .NET/COM+ available in a system (well, .NET Core only on non-MS,
| but still).
|
| while nushell stands on its own shoulders or if u like - allows
| control of other programs executed, but would not easily call
| into any API that is a language-specific one nor parse its output
| as structured one.
|
| so when comparing bash, zsh, nushell, pwsh one should take into
| consideration that these have different foundations and goals
| even. like perl stands on top of CPAN, all the JVM stuff on top
| of all classes, etc.
|
| although it is difficult to say why no one has created (to my
| knowledge) reasonable JVM-based shell, nor a python-based-one,
| since java targets such a large number of OS/platforms and
| provides such a broad library. perhaps because people assume that
| a shell program should follow the UNIX concept of one-program-
| does-one-thing-only. on the contrary - it would be a killer
| feature to have nushell be able to natively execute
| java/python/whatever API calls and use the structured output
| (like pwsh indeed).
|
| in essence - is very limiting to compare bash to pwsh only in the
| sense of 'how much can be done with only few characters', because
| this always leads to very opinionated and biased arguments and
| eventually discussions taken out of context.
| [deleted]
| iib wrote:
| @joseph8th mentioned a shell [1] earlier, that at least at
| first glance, seems to be a python + bash combination, similar
| to what powershell does with .net.
|
| [1] https://xon.sh/
| Andy-AO wrote:
| What is better about this tool than PowerShell?
|
| The README doesn't mention it at all, just that the tool is
| inspired by PowerShell.
| majkinetor wrote:
| Nothing. Lets be realistic.
|
| Even if it goes mainstream it will be decade behind PowerShell
| in conceivable future.
|
| While I appreciate the enthusiasm for developing shell, nothing
| usable here in years to come IMO when I can just use pwsh.
| the_biot wrote:
| Nushell missed the one feature that every Unix shell has: if it
| doesn't recognize the first word as a built-in command, look it
| up and run it as an executable. It's crucial, and nushell is
| missing out on an ecosystem of random shell commands to
| complement it as a result. This, of course, is what makes the
| Unix shell so great: the many little programs able to work
| together via pipelines.
|
| This makes nushell an interpreter command line, instead of a
| system shell.
|
| (Yes, you can "escape" by typing ^ before a word. That's not
| nearly the same thing.)
| jntrnr wrote:
| This is how Nushell works. If the command isn't an internal
| command, it will run it from you path.
|
| Curious what you tried that didn't work.
| bennyp101 wrote:
| Its the 2nd paragraph
|
| "If a command is unknown, the command will shell-out and
| execute it (using cmd on Windows or bash on Linux and macOS),
| correctly passing through stdin, stdout, and stderr, so things
| like your daily git workflows and even vim will work just
| fine."
| the_biot wrote:
| Argh, how did I miss this. The ^ is just for overriding
| built-ins with external executables. Apologies!
|
| Clearly I hadn't tried nushell -- this feature I thought
| missing was a big no for me. I have now, and this is
| definitely worth a try. Thanks all!
| ilyash wrote:
| Shameless plug: https://github.com/ngs-lang/ngs - Next Generation
| Shell
|
| Compared to other modern alternatives, NGS is "programming
| language first".
|
| Repository of scripts written in NGS, aptly named "NGS Scripts
| Dumpster" - https://github.com/ngs-lang/nsd
| korse wrote:
| I don't get these sorts of efforts.
|
| 'Let's make something complex appear intuitive by adding more
| complexity'.
|
| I really respect the work that has gone into this project, but no
| thanks.
| johnfn wrote:
| But that _can_ work. Just look at Google: massively complex
| product and problem, but sure appears pretty simple to the
| layman - I just type some words into the box and hit enter!
| dmitriid wrote:
| Test it with Casey Muratori's benchmark:
| https://github.com/cmuratori/termbench
|
| Context: https://twitter.com/cmuratori/status/1401761848022560771
| HajiraSifre wrote:
| That program is for testing terminal emulators, not shells.
| dmitriid wrote:
| Ah, true. Got confused there.
| Tepix wrote:
| This seems like a missed opportunity to call it "nutshell"!
| rincebrain wrote:
| This feels extremely like PowerShell, from all the examples, and
| even cites "draws inspiration from projects like PowerShell", so
| "a new type of shell" feels very disingenuous unless it has
| additional novel properties that aren't evident just from these.
|
| There's also no support for variables yet if the page is to be
| believed, which means there's 0 chance of me using this for more
| than 5 minutes right now.
|
| (I'm not trying to say this project isn't worthwhile, just that
| many other people in the thread currently seem to be entirely
| uncritical.)
| Macha wrote:
| I think to most people who've only used as Powershell as "That
| windows shell with the blue background and built in unixy
| aliases", getting into Powershell itself still qualifies as a
| "new type of shell", so I'm willing to extend that credit to
| other shells trying the same paradigm.
| rincebrain wrote:
| I'd agree that getting into PS from cmd counts as a new
| paradigm, or that getting into Nushell without Powershell
| experience is as well (based on the examples), but at the
| point where PS has been shipped with Windows by default for
| many years now, and Nushell runs natively on Windows, I think
| it's reasonable to disagree with a claim of "a new kind of
| shell".
|
| I also think it's reasonable for people to say it's justified
| - there's certainly, as you and others have remarked, a
| decent argument to be made for that.
|
| But for me, "different from many common shells, but all the
| same functionality has been bundled in one shell before"*
| strongly violates my expectations for "new kind of shell".
|
| * - I am not trying to definitively state they have no new
| functionality, I absolutely have not dug in deep enough, just
| that I did not see any examples of it, which I would have
| expected prominently.
| kstenerud wrote:
| > This feels extremely like PowerShell, from all the examples,
| and even cites "draws inspiration from projects like
| PowerShell", so "a new type of shell" feels very disingenuous
| unless it has additional novel properties that aren't evident
| just from these.
|
| There's HN-style nitpicking, and then there's this.
| rincebrain wrote:
| I'm sorry, but I'm not actually sure what you're trying to
| express here.
|
| My initial interpretation is that this is a level beyond
| typical nitpicking, but I'm not sure how that follows?
| kstenerud wrote:
| "A new type of shell" is a bit of marketing text to express
| the fact that this shell doesn't follow in the footsteps of
| most other shells (bash, zsh, fish, etc) in terms of
| treating things as blobs of text (which allows for a number
| of innovations). The fact that the author even states that
| it's partially inspired by Powershell demonstrates that
| he's aware of the similarities (and has in fact cribbed
| many ideas from it).
|
| Calling his marketing line "disingenuous" comes across as
| very petty nitpicking that adds nothing of value to the
| discussion.
| rincebrain wrote:
| Ah, I see. Thank you for explaining.
|
| The part that bothered me was not that they described
| something that shared some concepts with PowerShell as "a
| new kind", but that I did not see any illustration of
| entirely novel features in the examples that followed. As
| a sibling comment remarked, they feel I'm quite mistaken,
| and there are very positive distinctions illustrated in
| the examples, but I took a look at them again, and it's
| still not clear to me what they mean.
|
| I think I don't see why it's unreasonable for something
| which advertises cross-platform support to be compared to
| common shells on all those platforms, not just
| originally-*ix ones? That is, I think it's totally
| reasonable for you to think the tagline is justified
| solely by the differences in those shells, even if I
| disagree, but I don't see why you think it's unreasonable
| for me to hold this view?
| kstenerud wrote:
| It's not a question of precision, but rather one of
| convention. In this case, the convention is that a
| marketing line glosses over huge swaths of reality in
| order to give a simple and compelling narrative (people
| like things to appear simple, even if they're not - and
| even if they KNOW they're not). So calling out
| imprecisions and inaccuracies in this context reflects
| poorly upon you because everyone is already aware of the
| unspoken assumptions being made, and take criticisms
| about things already covered by the assumptions as
| unnecessary and irritating pedantry. As in a "Yes, we
| KNOW that it's not technically 100% accurate, please stop
| being annoying." sort of response.
|
| From my impression of your word choice and sentence
| structure, I'm making the assumption that you have
| autistic traits, which is why I'm explaining in more
| detail and on a social level.
| rincebrain wrote:
| I appreciate you attempting to explain.
| wccrawford wrote:
| FWIW, I don't think "it's marketing" is a valid excuse
| for them saying things that aren't true. It's _not_ a
| "new kind of shell" because it's mimicking things that
| already exist. The author even _knows_ about those things
| and cites them.
|
| I do not accept the idea that it's okay to make false
| claims to create a narrative, marketing or otherwise.
|
| And I'm not on the spectrum.
| uglycoyote wrote:
| I took it to mean that it was a new type of shell from the
| perspective of unix/osx users who were presumably their target
| audience, and who are an audience who might either not know
| what PowerShell is about our discount it is just a "windows
| thing" and therefore not relevant to their life. So "new" in
| the sense of "new to you".
|
| You could probably point to just about any technology that
| claims to be new and pull it apart and find that it is mostly
| derivative of existing technology and ideas
| rincebrain wrote:
| Sure, all work is theft, for some value of theft, but as I've
| said in a couple of other replies:
|
| * "all these ideas have been done before, in various places"
| is one thing, "all these ideas have been done before in one
| program in the same role on all the same platforms" makes me
| feel like "new [to users who haven't used this other thing
| shipped with the OS for years on one of the platforms]" is
| insufficient to use without more explicit qualifiers
|
| * I may be oblivious and missing some cool example, but the
| flip side to "all ideas implemented before" is "no new
| tricks", and when someone describes something to me as "a new
| type of X", I really expect at least one novel thing or
| composition of things to be present.
|
| After all, I wouldn't describe TIFF as a "new type of image
| format" just because many people who haven't touched
| photo/graphics editing probably haven't encountered it, or
| IE4 as "a new type of web browser" (now) just because a
| significant fraction of internet users are not old enough to
| have used it when it had market share. (When it was first
| released, Active Desktop, for example, while a security
| nightmare, was indeed a new thing for almost all users.)
| gexla wrote:
| https://github.com/nushell/nushell#progress
|
| "Nu supports variables and environment variables"
| rincebrain wrote:
| That page was edited an hour ago, so that was presumably a
| stale example. I'm glad to be wrong!
| jupp0r wrote:
| Have you used PowerShell much? The examples in the Readme make
| it obvious that it's very different (in a good way).
| brushfoot wrote:
| I use PowerShell extensively, and there are no significant
| differences in the README examples. They're basically
| rebranded PowerShell statements.
|
| I see minor syntax differences, for example in the comparison
| operators. Nothing that would it would be worth losing the
| .NET BCL or PowerShell's cmdlets for.
| rincebrain wrote:
| I use PowerShell daily, though I do not, for example, develop
| nontrivial modules for it.
|
| Could you provide an example of what I'm overlooking?
| mattbee wrote:
| I came here to say something similar. The question I need
| answered in the README is - why would I invest time in learning
| this _instead_ of Powershell?
|
| My muscle memory for bash is pretty strong, but when I have to
| do Windowsy stuff, I end up picking up a little bit more
| Powershell each time and find it pretty neat.
|
| So I'd be interested to know what it does differently, and
| couldn't find that answer.
| lta wrote:
| I stopped reading at "rather than thinking of services and input
| as a stream of text", horrified. Why would we do that ? KISS !
| heinrichhartman wrote:
| By the same reasoning: Would you not use databases because they
| have a schema? or JSON...? Heck, even utf-8 could be too
| complicated.
| lta wrote:
| You have a point. That sounded like pure conservatism, and to
| some extent it is. But still, text is simple and that what
| makes shell powerful, trying to move to higher level
| abstraction is has a chance to create fragmentation and break
| the solid foundations on which Unix is built.
| jbverschoor wrote:
| Because parsing text is shit. Good luck AWK'ing everything.
| Datastreams are simple.
| lta wrote:
| It's often better than trying to figure out the weird formats
| all the tool would use otherwise
| jbverschoor wrote:
| So start outputting something like json. And render it in
| the console as an ascii table
| tomduncalf wrote:
| Looks pretty cool.
|
| Anecdotally, I found switching shell to be more of a challenge
| than expected - I've been using (oh-my-)zsh for years and decided
| to try fish, but all the little differences were too annoying for
| me to get used to - I guess you build up a lot of "muscle
| memory"! That said, I probably just use the same commands most of
| the time. If you were doing more advanced stuff maybe it makes
| more sense to invest the time
| silentguy wrote:
| I think you can achieve most of the fish features in zsh with
| the help of plugins. The most compelling feature of fish was
| history substring search. You type something, press up button
| and you get a command in history with that substring. I used
| 'history-substring-search' plugin to achieve that. There are
| also 'syntax-highlighting' and 'completion' plugins which bring
| fish shell features to zsh. I use prezto for its speed after
| getting annoyed by oh-my-zsh slowness.
| AprilArcus wrote:
| I wonder if this could be accomplished in a more general way with
| a fourth standard file descriptor for structured data. stdjson
| basically.
| chubot wrote:
| What's wrong with plain old stdout? Lots of people do this with
| JSON (jq, etc.) and CSV or TSV (csvkit, etc.), XML/HTML, and
| more.
|
| That's how I generate much of the https://www.oilshell.org/
| site. It's just a tree of files and various shell commands,
| some of which I wrote myself.
|
| I do think we need something better than CSV and TSV for
| tabular data though. They both have serious flaws (not being
| able to represent values with tabs, etc.!)
| carlhjerpe wrote:
| I had this thought half a year ago. Anything not to have to
| parse text make me happy. Though i guess learning to parse
| command output helps you learn how to parse other text down the
| line.
| xpe wrote:
| I see this as requiring considerable work. For JSON, I don't
| see the payoff (relative to more expressive type systems). JSON
| was designed to work within different constraints. All in all,
| this suggests moving beyond JSON.
|
| Sometimes the _new_ ways are best...
|
| I often find that redesigns / rewrites can be transformative.
| The same benefits less often accrue to incremental changes.
|
| Practically, in my experience, when a group (or organization)
| is not under a severe time and budget crunch, redesigns seem
| more palatable. The results are more likely to be _simpler_ ,
| even if they are not as familiar.
| tgv wrote:
| A pipe only conveys stdout. You could redirect 4>&1
| 1>/dev/null, but you'd have to rewrite all tools to generate
| both stdout and stdjson anyway.
| oarsinsync wrote:
| > You could redirect 4>&1 1>/dev/null
|
| For anyone confused by this, 1 is the output to stdout, and 4
| is being redirected to where 1 goes, which is stdout.
| Unrelated to that, 1 (what's actually being output to stout
| by the application) is being redirected to /dev/null.
|
| The order of operations matters. If 1 was redirected to
| /dev/null first, then 4 would also end up in /dev/null. As it
| stands now, that doesn't happen.
| tgv wrote:
| Good one. I did look it up before I posted, too. I'm never
| 100% sure.
| im3w1l wrote:
| So you are supposed to read it from right to left? "First
| take 1 and throw it away. Next put 4 in 1." Is that how it
| works?
| kubanczyk wrote:
| Not quite. Left to right: copy the descriptor 1 onto
| descriptor 4, change descriptor 1 to result of
| open("/dev/null").
|
| The >& is for copying the descriptor not for aliasing
| ("hardlinking") it.
|
| The descriptor is the "fd" argument, e.g.:
|
| write(int fd, const void *buf, size_t count)
| vultour wrote:
| No, it's like assigning variables. The second part
| overwrites the value of 1, but the first part is still
| using the old value.
| dgrunwald wrote:
| No, it's from left to right. It's basically just syntax
| for a series of dup2() calls.
|
| "4>&1 1>/dev/null" means:
|
| streams[4] = streams[1]; streams[1] = open("/dev/null");
| colourgarden wrote:
| The title is somewhat misleading and makes it seem like this is a
| GitHub company initiative rather than a project just hosted on
| GitHub.
|
| I've not seen this title format on HN before. Could it be
| changed?
| redmaverick wrote:
| I got excited thinking it was an official Github project.
| xpe wrote:
| I think it is very likely "disagreement" in this thread is
| simply based on people seeing different titles at different
| times. There are some possible causes:
|
| 1. The submitter may provide an initial title
|
| 2. HN moderators may adjust the title
|
| 3. GitHub may show different titles based on the user's login
| status (I'm not sure myself, I'm writing this based on what I
| read in another part of this thread)
|
| Therefore, I make this request of HN commenters: Since titles
| on HN can change, please quote the exact title that confuses
| you.
|
| More broadly, it may be useful to _always_ quote the text you
| are responding to.
| thomasahle wrote:
| Right. It doesn't seem important where the project is hosted.
| thomastjeffery wrote:
| Not only is the place the project is hosted totally irrelevant
| to discussion, it seems like it would make more sense for this
| post to link the project website (www.nushell.sh/) instead of
| the GitHub repo.
| jtokoph wrote:
| The title is the actual value of the title html tag on the page
| roblabla wrote:
| Heh, that's interesting: When you're logged in, the title tag
| changes to drop the "GitHub -" prefix.
| tim-- wrote:
| SEO strikes again!
| foobar33333 wrote:
| Considering people often search 'github project name' it
| probably makes sense.
| corobo wrote:
| It could go at the end just as easily like every other
| site though
| laurent123456 wrote:
| Same, I thought it was a GitHub project. There are often links
| to GitHub pages on HN and I don't think they generally have the
| "GitHub" prefix. It's not relevant anyway where the code is
| hosted.
| s_dev wrote:
| I can see the confusion but it didn't confuse me. If it's a
| GitHub product it would only be a blog post I would expect not
| actual code ironically.
| hibbelig wrote:
| I think the "nushell/nushell" part makes it clear which repo it
| is talking about.
| agumonkey wrote:
| I'm in that camp. I read the URL without issues
| cabalamat wrote:
| I think just "nushell/nushell: A new type of shell" would be
| a clearer title.
| redmaverick wrote:
| no.. I didn't find it clear..
| cbolton wrote:
| I didn't find it clear, I also thought it was a GitHub
| project.
| bamboozled wrote:
| Really seemed like a GH project to me.
| thatsnotmepls wrote:
| I found it clear it wasn't a GitHub project.
| bee_rider wrote:
| The point of a title is to be obvious to everyone (to the
| extent possible) -- the fact that we found it obvious
| doesn't remove their confusion.
| andredz wrote:
| It wasn't clear to me that any of the interpretations
| was, well... clear, and had to check the comments (I
| could have checked the repo too).
| irjustin wrote:
| Yeah i thought it was like "Github - Atom Editor"....
| corobo wrote:
| That's on GitHub in fairness. Left is logged in.
|
| https://cdn.imgy.org/DOyx.png
| mdoms wrote:
| dang will most certainly change this title when he spots it. I
| have been tracking HN title changes and they follow a very
| predictable format. Here are some recent results,
| Universities have formed a company that looks a lot like a
| patent troll was Universities Have Formed a Company That
| Looks a Lot Like a Patent Troll Linux with
| "memory folios": a 7% performance boost when compiling the
| kernel was Linux with "memory folios": got a 7%
| performance boost when compiling the kernel
| Strategic Scala Style: Principle of Least Power (2016)
| was Strategic Scala Style: Principle of Least Power (2014)
| The rise of E Ink Tablets and Note Takers: reMarkable 2 vs Onyx
| Boox Note Air was The Quiet Rise of E Ink Tablets -
| ReMarkable 2 vs. Onyx Boox Note Air Big tech
| face EU blow in national data watchdogs ruling was EU
| court backs national data watchdog powers in blow to Facebook,
| big tech Emacs Love Tale by sdp was
| Emacs Love Tale by Sdp Future from a16z
| was Andreessen Horowitz goes into publishing with Future
| Richard Feynman's Integral Trick (2018) was Richard
| Feynman's Integral Trick The Tinkerings of
| Robert Noyce (1983) was The Tinkerings of Robert Noyce
| NIH study offers new evidence of early SARS-CoV-2 infections in
| U.S. was NIH Study Offers New Evidence of Early SARS-
| CoV-2 Infections in U.S. Time to sunburn
| was It's surprisingly easy to get a sunburn
| The home computer as a cultural object is physically vanishing
| (2007) was The home computer as a cultural object is
| physically vanishing Mackenzie Scott gives
| away another PS2B was Billionaire Mackenzie Scott gives
| away another PS2bn A pilot program to include
| spirituality in mental health care was Psychiatry Needs
| to Get Right with God What we learned doing
| Fast Grants was What We Learned Doing Fast Grants
| Joplin - an open source note taking and to-do application with
| synchronisation was An open source note taking and to-do
| with synchronisation capabilities Show HN:
| Influence, a Go-inspired 1-minute board game was Show HN:
| Influence, a Go-inspired 1min board game J
| Concepts in SuperCollider was J Concepts in SC
| (SuperCollider) Joplin - an open source note
| taking and to-do application with synchronization was
| Joplin - an open source note taking and to-do application with
| synchronisation was An open source note taking and to-do
| with synchronisation capabilities Forzak: A
| website that curates high-quality educational content was
| Forzak: A website that curates high-quality educational content
| on the Internet DraftKings: a $21B SPAC
| betting it can hide its black market operations was
| DraftKings: A $21B SPAC Betting It Can Hide Its Black Market
| Operations We're no longer naming suspects in
| minor crime stories was Why we're no longer naming
| suspects in minor crime stories Operation
| Midnight Climax: How the CIA Dosed S.F. Citizens with LSD
| (2012) was Operation Midnight Climax: How the CIA Dosed
| S.F. Citizens with LSD Modelplace: AI Model
| Marketplace by OpenCV was Modelplace, the AI Model
| Marketplace by OpenCV Don't just shorten your
| URL, make it suspicious and frightening (2010) was Don't
| just shorten your URL, make it suspicious and frightening
| Kuhn's Structure of Scientific Revolutions - outline (2013)
| was The Structure of Scientific Revolutions
| How Indian Zoroastrians helped shape modern Iran was An
| Indian Religious Minority Shaped Modern Iran
| RFC for 700 HTTP Status Codes (2018) was RFC for 700 HTTP
| Status Codes RFC for 700 HTTP Status Codes
| (2012) was RFC for 700 HTTP Status Codes (2018) was
| RFC for 700 HTTP Status Codes How to Be a
| Stoic (2016) was How to Be a Stoic
| Researchers fear a scenario in which smart speakers feed
| sleepers subliminal ads was Are advertisers coming for
| your dreams? Google Messages end-to-end
| encryption is now out of beta was Google Messages end-to-
| end encryption no longer in beta Stabel: A
| pure concatinative programming language, now with modules
| was Stabel v0.2.0-alpha: A pure concatinative programming
| language, now with modules Recording of the
| week: A Yanomami ceremonial dialogue was Recording of the
| week: A Yanomami ceremonial dialogue Stabel: A
| pure, concatenative and statically typed programming language
| was Stabel: A pure concatinative programming language, now with
| modules was Stabel v0.2.0-alpha: A pure concatinative
| programming language, now with modules
| Technology Saves the World was Andreessen: Technology
| Saves the World Why bother with old
| technology? (2013) was Restoration of vintage computers -
| Why bother with old technology? What Happens
| If an Astronaut Floats Off in Space? (2013) was What
| Happens If an Astronaut Floats Off in Space?
| Legal expert says Tether and Binance Coin are likely picks for
| SEC lawsuit was Legal expert says Tether and Binance Coin
| (BNB) are likely picks for SEC lawsuit If you
| think psychological science is bad, imagine how bad it was in
| 1999 was If you think Psychological Science is bad,
| imagine how bad it was in 1999 Six charged in
| Silicon Valley insider trading ring was Six Charged in
| Silicon Valley Insider Trading Ring
| tsjq wrote:
| same here. I thought it is GitHub project
| stinos wrote:
| Seems pretty well designed. Though the decision to be able to
| refer to the properties of data in a pipe directly with their
| names might cause some confusion in the end (the 'size' in 'ls |
| where size > 1'). Ok it's succinct, but it's also a bit weird
| that the loop variable (what this basically is in a pipe) is
| treated different than all others. Not that e.g. PS' $_ is so
| great, but at least it's obvious: it's a variable just like all
| others.
| chalst wrote:
| This is a feature that Powershell gained and it is very useful.
| pama wrote:
| When I think of a new shell I want to understand quoting and the
| special meaning of characters. Bash has found a decent
| compromise; what does nu plan to do? The documentation is pretty
| scant, but perhaps that's because the language is still
| developing:
| https://www.nushell.sh/book/types_of_data.html#strings
| ajeetdsouza wrote:
| Shameless plug: zoxide recently added support for Nushell. It's a
| smarter cd command for your shell (similar to z or autojump).
|
| https://github.com/ajeetdsouza/zoxide
| lsllc wrote:
| Sort of looks like a modern take on VMS!
| yetanother-1 wrote:
| Very promising project that I hope it will take off and succeed.
|
| I recently switched to zsh with the addition of oh-my-zsh and I
| am happy how it has features like auto completion and command
| validation of some sort, but this could take it to the next
| level.
|
| I am just afraid to change to it and be disappointed about some
| incompatibility issues or bugs / crashes.
|
| I will observe and wait until it's quite popular to hop on I
| think.
| Offpics wrote:
| Try fish shell. It has auto completion by default and is easy
| to configure with web interface "fish_config", no need to rely
| on some community repo like oh-my-zsh. There can be bugs if you
| set it as default shell but i just append "fish" at the end of
| my .bashrc :)
| ar_lan wrote:
| It's so interesting - it seems that fish is getting more and
| more popular lately.
|
| I tried it ~7 years ago and thought it was severely lacking,
| so I just stuck with zsh and have never really had a reason
| to look back.
|
| Maybe I'll check out fish again at some point - what features
| does it have that drew you to it?
| drcongo wrote:
| Almost everything that you might get from oh-my-zsh is
| built in and it's _much_ faster. I've been using Fish for a
| few years now and I love it.
| Macha wrote:
| I moved from zsh + oh-my-zsh to fish a couple of years ago.
|
| The main reasons were:
|
| 1. It had a lot of qol features I liked from zsh _by
| default_ without requiring a significant config
|
| 2. Prebuilt zsh configs like oh-my-zsh have been pretty
| commonly quite slow in my experience, which fish fixes.
| clashmeifyoucan wrote:
| not OP but the two features of fish that stood out for me
| so much that I make it my default shell on remote servers
| are
|
| 1) the autocomplete suggestion as you type a command [1]
|
| 2) scrolling thru commands after partially writing one only
| shows entries that match the written text
|
| 3) knowing if a command will work before pressing enter --
| saves from a lot of gotchas.
|
| all of these read like features nice to have but not
| essential, but when you're using something every day, it's
| worth it :)
|
| [1]: https://fishshell.com/docs/current/tutorial.html#autos
| uggest...
| IshKebab wrote:
| I use Oh-my-zsh too but I hate that it constantly asks me to
| update itself and it isn't exactly the quickest update either.
|
| Either update automatically in the background or don't tell me
| about updates at all. Don't constantly nag me when I start new
| shells!
| tasuki wrote:
| I used to use oh-my-zsh and never really understood it. Turns
| out what I mostly wanted was `zsh-autosuggestions` and `zsh-
| syntax-highlighting` plugins, plus some sane history settings
| [0]. I've been oh-my-zsh-free for three months, my computers
| are now less cluttered and more straightforward.
|
| [0]: https://github.com/tasuki/dotrc/commit/e3769134e758d02a9
| 47ef...
| sva_ wrote:
| I also uninstalled it pretty quickly after having tried it.
| Additionally, I use powerline, fzf, and easy-motion in zsh
| though.
| silentguy wrote:
| I started using zsh with oh-my-zsh as it made me realize how
| powerful, ergonomic and productive my shell could be. I was
| annoyed by the slowness. I thought of moving to barebones zsh
| with the few plugins. My colleague suggested that I used
| prezto. I have been using prezto ever since with my preferred
| plugins enabled. And, I have been happy with my setup. It has
| all the features I need without the slowness of oh-my-zsh. I
| ended up getting all the features of fish shell using
| plugins. I didn't want to use fish because it's syntax is not
| compatible with bash which I have to write at work.
|
| Give prezto a try. You might like it.
| tidbeck wrote:
| I had the same issue but your comment made me look up if
| there is something to do about it. Both things are possible
| https://github.com/ohmyzsh/ohmyzsh#getting-updates
| j1elo wrote:
| Thinking this is so cool! I was wondering if seriously buying
| into an alternate shell like this would be worth it in the long
| run.
|
| Would really love to read from people who use(d) an alternative
| shell, both success and failure stories.
|
| I cannot shake from my head the idea that buying into a non-
| standard shell will only work for personal projects in one's own
| workstation, but it won't fly too far for company work because
| you'd then be introducing an implicit dependency on your special
| snowflake non-standard runtime. Which is something we came to
| accept and assume for interpreted languages (Python, Ruby, Node,
| etc.) but I'm not yet ready to assume for shell scripts.
|
| So right when I was going to test Nushell, I discover there are
| also other shells like Elvish [0] and Oil which supports
| structured data [1]. Now on top of my hesitations I'm adding
| decision paralysis :-]
|
| [0]: https://elv.sh/
|
| [1]: https://www.oilshell.org/
|
| Lots more shells:
| https://github.com/oilshell/oil/wiki/Alternative-Shells
| joseph8th wrote:
| I've been using Xonsh[0] for a couple years as my daily driver
| and I swear by it. I'm also a Python dev so that's part of the
| appeal. It's billed as the "unholy union" of Bash and Python.
|
| [0] https://xon.sh
| rtpg wrote:
| Xonsh is also my daily driver for years and years. Combined
| with direnv I have really not missed much of anything from
| other shells. So much stuff either works out of the box or
| has some little hacky wrapper to handle it.
| joseph8th wrote:
| Yup. I'm a huge fan of the vox plugin approach to python
| and venv management. No more virtualenv hacking the
| shell... it's a first-class citizen. Plays nice with pyenv
| too
| smichel17 wrote:
| This sounds nice enough that I'm considering installing
| xonsh just for python development
| AnIdiotOnTheNet wrote:
| I'm generally supportive of the effort to replace the archaic
| shells that dominate the unix landscape, but unfortunately none
| have yet met my personal desires.
|
| It seems like a lot of the developers of these shells create
| them to supplement the common unix toolset, but I really want a
| complete replacement. Ideally, the shell itself would be a
| completely dependency-free static executable, with a built-in
| command set that includes functions to interface with all the
| kernel's user space accessible features, acts as a repl, with
| sensibly named commands, and a simple method for interfacing to
| and from any other program. In short, I guess I'm looking for
| something to act as the basis of a completely new environment
| on top of Linux. As it is, most of these do not even meet the
| first of the criteria.
| ironmagma wrote:
| FWIW, nushell is much more of this than it appears. While
| many commands share names with Unix commands, that is the
| only similarity for quite a few, since they are rewritten to
| return structured data instead of text.
| AnIdiotOnTheNet wrote:
| From what I recall about nushell, it only scores 2/5 of my
| criteria.
| ironmagma wrote:
| Right, it's still very early and something needing to be
| contributed to. However I have spoken to the creator
| (regretfully I haven't had as much time to contribute as
| I would've liked); he is very open to improvements and
| the direction of the project is pretty open.
| aerique wrote:
| I don't know if fish counts as an alternative shell since it is
| still pretty close to bash and zsh, just with better defaults
| requiring less configuration (similar to i3wm with respect to
| "better defaults").
|
| I just use it as interactive shell and for scripts I use
| `/bin/sh`. So I don't really run into a lot of problems, only
| sometimes with scripts that do not have a proper
| `#!/path/to/shell` declaration at the top.
|
| ("better defaults" is of course entirely subjective but for
| fish, i3 and Doom Emacs they mostly align with my preferences)
| christophilus wrote:
| I've been poking around with Sway, coming from Gnome (which I
| mostly love). What got you into i3 vs a normal desktop, and
| how long did it take you to realize it was a good fit?
| maccard wrote:
| I tried fish for a while. The differing syntax between fish and
| bash for fundamental things mean I was running all my scripts
| through bash anyway, and if I wanted to share them/use them
| elsewhere in the company it had to be bash, so I swapped back
| to bash.
| okamiueru wrote:
| If you're running scripts, what difference does it make that
| you use fish? You're not really supposed to write scripts for
| fish, unless it is meant to be used be the fish shell itself.
| A shebang on the top of your script will invoke the script
| with the right executable, and whether you called it from
| bash, zsh or fish would make no difference.
| maccard wrote:
| > You're not really supposed to write scripts for fish
|
| Given that 95% of my time in a shell is running a script, a
| shell that doesn't do that well isn't a great fit for me.
|
| > A shebang on the top of your script will invoke the
| script with the right executable,
|
| Assuming the person who wrote it had the foresight to do
| so. That person isn't always me, and if I have to manually
| check if each script I run has a shebang, I should just
| default to running them in bash.
| hibbelig wrote:
| I haven't seen a shell script in ages that was missing
| the shebang. Is this common in some places?
|
| I've started to write dash scripts because that seems to
| be reasonably posix and bash on macOS is ancient.
| maccard wrote:
| Any random blog post that you find with instructions to
| run something in a shell that uses a variable just won't
| work copy and pasted, you now need to either modify them
| for your esoteric shell, or wrap them in a script to be
| ran through bash
| IggleSniggle wrote:
| I don't think I've _ever_ seen a script written without
| the shebang.
|
| Btw, you can get around the ancient bash in macOS by
| installing a more modern bash and invoking with
| /usr/bin/env bash as your shebang. Not sure if that's a
| great idea, mind you, but if you're already writing
| scripts in something non-portable, it's an option.
| maccard wrote:
| There are hundreds of sh files on github that don't have
| a shebang. Just because you don't write them and your
| colleagues don't doesn't mean they don't exist in the
| wild.
| IggleSniggle wrote:
| I didn't mean to imply that they didn't exist nor that it
| might not be important to account for them in some
| contexts. I meant only to convey my own personal
| experience: that it had never occurred to me that I might
| need to account for a missing shebang, since providing an
| interpreter for a script via shebang is all I have ever
| personally encountered.
| traviscj wrote:
| Yeah thing $T _might_ (but probably won't) happen, so the
| idea is automatically terrible.
| NikolaeVarius wrote:
| I would consider a person who doesn't use a shebang to be
| bad at their jobs.
|
| Even the most basic of tutorials will include it even if
| it means nothing to the user.
| toxik wrote:
| So, instead of just typing shell commands, you type
| something else, but as soon as you need a shell script, you
| have to go back to shell commands.... Why not just cut out
| the middleman?
| okamiueru wrote:
| Answer to the first question: yes. Answer to the second
| question: because bash is a rather poor terminal shell.
|
| In my experience, the middleman you mention doesn't
| exist. Or, if anything, it is a very tiny man that hardly
| gets in the way. It's either a one-liner with a syntax
| change you can pick up in 5 minutes, or it falls under
| any combination of these:
|
| - might as well belong in a script
|
| - the complicated stuff is in awk or the likes
|
| - you can just enter bash for any copy-pasted bashisms
|
| - you can execute it explicitly with bash -c
|
| In any case, none enough of a hassle that it could
| demerit the immense productivity benefit I've gotten from
| fish. The only regret I have on that matter is not having
| ditched it sooner. Use bash to run scripts, or even
| better, sh. Use a different shell to make your life on
| the terminal better. Doesn't need to be fish, zsh is
| pretty good too.
|
| If I can offer any advice: if you still want to stick
| with bash, at the very least take a look at fzf,
| https://github.com/junegunn/fzf , aside from fish/zsh
| it's the best and most lowest hanging fruit.
| toxik wrote:
| I personally use zsh, bash is too primitive with regards
| to its user interface (line editing, searching, vi keys,
| etc.) The syntax however is my key point here, I often
| take my commands and smack them into Makefiles for
| example.
| Apofis wrote:
| I used fishshell for years, and the bottom line ended up
| being that it created enough mental overhead to be a burden
| because it diverged from the UNIX norm too much. Sort of like
| the colemak keyboard layout, sounds great in theory, in
| practice, not so much.
| systematical wrote:
| Fish user here. I've accepted having to drop down to bash
| here and there. No big deal for me.
| pydry wrote:
| I went through the same thing.
|
| It also got on my nerves that scripts which did not identify
| themselves correctly as bash would run in [ whatever hot new
| shell im running ], often with bizarre results.
| salmo wrote:
| That's not entirely weird to me.
|
| For the longest time bash was in various states of disrepair
| on different Unixes. I could make it segfault pretty easily.
|
| I wrote scripts that had to run across Linux, BSD, HP-UX,
| Solaris, and AIX at the time. So we relied on a ksh88
| implementation on each. Whether it was AT&T, mksh, or pdksh,
| it was fine. Couldn't rely on 93isms, but basically anything
| POSIX was cool.
|
| I used ksh93 interactively for the longest time. But then
| Linuxes stopped testing interactive use w/ their packages and
| it became unusable (looking at you RedHat). So I used bash
| interactively but still wrote those ksh scripts.
|
| These days, I use zsh locally on MacOS and BSD, but mostly
| write bash scripts for those and Linux. I still stick to the
| POSIX habits I have for portability. But the variances are so
| less. The only one that annoys me is the "does sed -i do in-
| place" game.
|
| I don't think my interactive shell and target scripting shell
| have ever matched 1:1 in feature set. And what I slap
| together interactively or for 1-off script, I would never do
| for a "real" script. And that's a thing that bugs me with a
| lot of shell scripts I see in the wild.
|
| A "real" script should make very little assumptions, fail
| safely, be low on resource utilization to not risk impacting
| a business workload, and be maintainable. I write everything
| real like it might be run thousands of times accross
| thousands of hosts. Even when I didn't intend for it to be,
| I've caught it in the wild because someone borrowed what I
| did.
|
| I do love shellcheck, because it teaches our newer folks good
| habits and they're used to that kind of feedback in other
| languages. It catches so many things that make me cringe.
| It's not perfect, of course, but pretty great.
|
| When I started out, I worked 9-6 and the Unix sages in my
| group worked later hours. So they'd walk through my work on
| the RCS host and I'd come into the morning with a critique in
| my email. If I didn't understand, I could hit their desk
| after lunch and they would patiently explain to me. I love
| them for it, but it is nice to have tools without a 24-hour
| feedback loop.
| j1elo wrote:
| Shellcheck is nowadays a must for writing decent shell
| scripts. it is like a centralized knowledge base of all
| those brilliant minds that did the sanity checking for you
| in the old days :)
| mavhc wrote:
| It boggles my mind that people use a language where
|
| x = 0 doesn't work and x=$y is a security flaw
| gnubison wrote:
| > x = 0 doesn't work
|
| Maybe it's just me, but I love how the assignment syntax
| can be used just for a single command: 'MANPAGER=cat man'
| is a lot nicer than '(MANPAGER = cat; man)'.
|
| > and x=$y is a security flaw
|
| When is variable assignment a security flaw?
| zaphar wrote:
| if $y is untrusted input then you need to quote it or
| you've introduced shell injection attack to the script.
| cwalv wrote:
| Sometimes it's easier to use tools you know will be
| available than to ensure your tool of choice will be
| available everywhere you need it to be. JavaScript, esp.
| pre v6, is another example that makes almost no sense
| when you ignore its ubiquity
| neop1x wrote:
| I tried fish for a short while too and quickly realized
| everything depends on bash/dash. I then switched to zsh which
| is mostly compatible. I installed Oh My Zsh and a fish-
| inspired theme with line autocompletion and coloring and
| never looked back. But I still use zsh for the interactive
| prompt only, still writiiing #!/bin/sh scripts for maximum
| compatibility between platforms.
| sudhirj wrote:
| I wouldn't use a custom shell _in_ company work, but I'd use it
| _for_ company work. I treat custom shells like a custom
| keyboard or shortcuts in the OS. Shells can help a lot in your
| day to day command line ergonomics, like presentation (always
| know which branch and directory I'm on, time and time taken for
| commands) and ease of use (autocomplete, aliases, shortcuts).
| But I wouldn't script into them for professional work. Just
| plain bash in that case. We really don't want devs fighting
| over which shell to install on the servers, but everyone can go
| crazy on their own laptops.
| j1elo wrote:
| I agree... and any well written script will have a shebang
| that specifies the shell that shluld run it, anyway.
|
| For me, personally, I love having homogeneus systems put in
| place. In this case it means not having to switch my mind
| between _in_ and _for_ modes. Helps me avoid mistakes, having
| to keep less context up here. But it 's always interesting to
| read about other people's way of working.
| hibbelig wrote:
| If you want to make the systems homogeneous, then you need
| homogeneous teams, too. Maybe some team members prefer
| fish, others prefer zsh, still others prefer bash. Your
| suggestion means that everyone has to use the same shell
| for their command line.
|
| I find that it is better to allow each team member to have
| their own working environment: different (command line)
| shell, different editors/IDEs, different keyboard
| shortcuts. But everyone uses the same programming languages
| (counting shell as a programming language for scripts here)
| and the same build tools and the same linters.
| j1elo wrote:
| no no no, I meant that _I_ prefer using Bash everywhere,
| including my own machine, because anyway I 'll need to
| end up translating most stuff I write to a Bash or even
| POSIX compatible script so... as someone said in other
| comment, why not cut the intermediary step. It makes it
| easier for me, the less context switches the better
| production code I'll produce.
|
| But of course, I believe others should be free to make
| their own choices! As long as their choices don't end up
| affecting the quality of the code that ends up shared
| with the rest of the team...
|
| Which brings an interesting point: I don't have a problem
| at all with you using whatever shell you want. But I _do_
| have a problem if because you don 't use Bash in your day
| to day, you are less used to its ins and outs, you don't
| put in the extra work that is being as proficient with
| Bash than you are with your personal shell, and your
| scripts end up with bugs in how Bash arrays are treated
| (just a quickly made up example)
| sudhirj wrote:
| Yup. There are more shells than there are IDEs, keyboard
| switch types, keyboard layouts, and operating systems.
| Shell ideological wars get just as bad as emacs/vim and
| linux/Mac. Use whatever you want, but company IP is
| shbang'd to bash.
| OJFord wrote:
| > shbang'd to bash.
|
| Good.
|
| Better: #!/bin/sh
|
| Best: #!/bin/sh and also not assuming bash anyway!
| sudhirj wrote:
| If we're distributing software, maybe? Personally we
| control the hardware, so we know what we're running, but
| yeah, for libraries or packages this makes sense.
| roywashere wrote:
| Oh and how /bin/bash is bash3 on macOS instead of the
| contemporary bash5 by default. And how sh is dash on
| Debian, or Ubuntu, I forgot. Some of the reasons why I
| would prefer python3 scripts (or perl) over sh or bash
| dundarious wrote:
| Pretty annoying to reliably #! to python3 as well. Is it
| /usr/bin/python or python3?
| bobthebuilders wrote:
| I wouldn't say putting a sh shebang and assuming bash is
| better. With a bash shebang at least you're honest about
| it.
| OJFord wrote:
| Well yes, absolutely. I phrased that poorly, what I meant
| was like '/bin/sh is better... Especially if it actually
| works' or something.
|
| It's easily done though, I've often thought I've written
| something POSIX compatible and then had shellcheck say
| nope.
| worble wrote:
| > I cannot shake from my head the idea that buying into a non-
| standard shell will only work for personal projects in one's
| own workstation, but it won't fly too far for company work
| because you'd then be introducing an implicit dependency on
| your special snowflake non-standard runtime. Which is something
| we came to accept and assume for interpreted languages (Python,
| Ruby, Node, etc.) but I'm not yet ready to assume for shell
| scripts.
|
| Is it so bad? I run arch at home, I would never do that for a
| production server. I use rust at home, but it's unlikely to get
| introduced at my work any time soon. I use elm for solo
| projects, and I've never once convinced my managers to even try
| it (and believe me, I tried).
|
| Context switching is pretty normal, I wouldn't let that get in
| the way of trying something new and interesting. Personally I
| find elv.sh the sanest scripting language I've tried so far,
| and I wouldn't trade it back in for bash, even if I'm still
| forced to use it at work.
| basilgohar wrote:
| Perhaps someone already mentioned this elsewhere, but nothing
| forces you to use only a single shell. A shell, after all, is
| just a running process. Yoh can even launch it from another
| shell.
|
| As a GNU screen user already, I can imaginr having one of my
| default windows that load when I launch screen be nushell if I
| was so inclined. I can keep the rest as my default (e.g., bash
| or htop or whatever else I wany running there).
| lolc wrote:
| There is something very important that forces me to use a
| single shell: Habit.
| strzibny wrote:
| I tried and returned to Bash. There is something about using
| defaults.
| joepie91_ wrote:
| > Which is something we came to accept and assume for
| interpreted languages (Python, Ruby, Node, etc.)
|
| Tangential, but:
|
| - "Node" isn't a language, it's a JS runtime
|
| - There's no such thing as an "interpreted language", whether
| something is interpreted or not is a property of the execution
| environment, not of the language itself
|
| - The commonly-used runtimes for JS at least are JIT compilers,
| not "interpreters", and this can be true for some Python/Ruby
| runtimes too
| j1elo wrote:
| I didn't downvote your comment. But I guess some people did,
| possibly because you did the thing about stating several
| facts where all were true but none were relevant. I'd swear I
| read that this phenomenon even has a proper name but cannot
| recall it right now.
|
| (And for the record I know very well about the internals and
| technicalities about the words and names that I used: Node.js
| is the de-facto Javascript runtime for the backend, popular
| to the point that people commonly refer to it as "programming
| in Node"; Python and Ruby are just languages but their
| majority of users run their program with the default official
| interpreter, so through a metonymy we can refer to either
| even when actually talking of the other; and etc. For economy
| of the language and avoiding the pedantry, I grounded my
| comment on the most generally perceived notion about those
| technologies. You see, just to avoid unnecessarily long
| explanations like this one)
| breatheoften wrote:
| I use the fish shell and have for several years now.
|
| A few years back I did a startup with a friend -- a cross
| platform mobile product but with a mess of complex open-source
| c++ dependencies (which we forked and customized often) -- and
| we made the decision as we hired developers to over-specify
| some aspects of the machine environment to make it as easy as
| possible to share our development workflows. Note that
| "development workflow" is much more than just "i can run the
| app in docker" -- but rightfully includes -- I can efficiently
| run things in debugger, I can run the performance profiling
| tools in realistic ways, I can quickly execute and test a
| change someone else is trying to make, I can quickly share a
| change I'm making with someone else and be confident they can
| make realistic observations about it, i can setup a fast repro
| loop for some specific bug or feature ... etc.
|
| We did a pretty good job of getting the know now needed for all
| those workflows distributed across the team reliably with low
| effort despite some complicated and weird build system
| requirements associated with our dependencies.
|
| One of the big bang for buck tricks that helped more than I
| would've expected was to mandate that everyone had to use fish
| shell. This really reduces the number of weird effects from
| random things that people copy/paste into their bash
| initialization -- with the developer never imagining the
| strange knock off effects that will one day cause a tool they
| don't understand to behave in a flaky way for a reason they
| will never figure out ...
|
| The amount of terrible things that developers randomly
| accumulate in their bash initialization probably can't be
| underestimated ... there's probably more risk of "weird
| problems" associated with advice on stack overflow related to
| bash initialization than maybe any other topic ...
|
| So I personally think standardizing a team or startup on an alt
| shell can be a potentially good idea ...
|
| As another point of evidence -- I later headed devops at
| another startup that took opposite perspective -- "use your own
| machine and your machine can be configured however you want and
| you just have to figure out dev workflows on your own" and it
| was extremely difficult to share knowledge about how to
| accomplish a lot of these basic workflows ... doing anything
| beyond the most basic ways of interacting with the codebase
| often involved a rather large amount of hands on dev machine
| troubleshooting (can you send me your .bashrc and .profile and
| .bash_profile? ok type these commands ... ok now you can grab
| my branch and try this to have a look at the thing i'm trying
| to change ...)
|
| fish is reliable and stable though -- I'm not sure about using
| a shell that's not been around for awhile in this way ... but
| I'd support it I think if I already had personal experience
| that the shell was "reliable enough" ...
| [deleted]
| onetom wrote:
| use it as an interactive shell first, not for shell scripts.
|
| also, why would any dependency of your projects at work be
| implicit? all dependencies should be captured somehow, the very
| least in some documentation.
|
| at our company, we use shell.nix files to declare all of our
| dependencies, so everyone has the exact same software available
| on their development workstations.
|
| it's not a completely trivial thing to do, but worth investing
| into it, to lower the chance of surprises, which will happen
| when you can afford them the least...
|
| here is an example to get started:
|
| ``` with import (builtins.fetchTarball { name = "nixos-
| unstable-on-2021-05-16"; url = "https://releases.nixos.org/nixo
| s/unstable/nixos-21.05pre2893... sha256 =
| "1kilrk0ipvldf4rrn6aq6v2bj2jfhbz33cjb9w9ngqmbmr2f94wd"; }) { };
|
| let project-jdk = jdk11; clojure = callPackage ./deps/clojure {
| jdk11 = project-jdk; };
|
| in mkShell rec { buildInputs = [ coreutils cacert direnv nixfmt
| curl jwt-cli fd python3 nodejs (yarn.override { nodejs =
| nodejs; }) project-jdk clojure yaml2json modd
| devd overmind ]; shellHook = ''
| export LC_CTYPE="UTF-8" # so tar and rlwrap won't complain
| '';
|
| } ```
|
| it shows how u would use your custom package (for clojure in
| our case) and how would u pin there state of the whole package
| repository to a specific point in time.
|
| in the past I've used es, the extensible shell
| (https://wryun.github.io/es-shell/), this way, without
| bothering my colleagues with teaching them about it. they just
| git pull, press enter in a shell within the hour repo and
| direnv will pull down any new dependencies.
| rgoulter wrote:
| > also, why would any dependency of your projects at work be
| implicit? all dependencies should be captured somehow, the
| very least in some documentation. .... Nix.
|
| Because distributing software is hard, especially if things
| change. That's one big reason why Docker images will
| sometimes get used for development environments (like what
| VSCode supports).
|
| Nix is nice, and is a pretty good way of capturing those
| dependencies. But it's also difficult to customise, often
| lacking in documentation, and not used very widely.
|
| If you're not using something like Nix (i.e. most people),
| it's natural for dependencies to be quite implicit.
| darepublic wrote:
| It would be nice if the syntax could be very forgiving. So typing
| something such as 'show me the files over 12 mb' would work.
| Initially when I read the README it's what I thought it was.
| hyperpallium2 wrote:
| Need some description up front, not in the 5th section
| ("Philosophy" https://github.com/nushell/nushell#philosophy).
| Some ideas:
|
| "powershell for unix", "structured pipes", "pre-parsed text",
| "small, useful, typed tools loosely coupled."
| tonyedgecombe wrote:
| _powershell for unix_
|
| In general I really dislike _" [some other product] for [a
| different use case]"_. It might be accurate but many potential
| users might never have heard of PowerShell or if they have only
| have a vague idea of what it is.
| thefunnyman wrote:
| I find it hard to believe that someone looking into
| alternative shells would have never heard of PowerShell. I
| get that Windows isn't exactly most people's OS of choice,
| but the existence of PowerShell is widely known.
| jupp0r wrote:
| powershell for unix is ... powershell:
| https://docs.microsoft.com/en-us/powershell/scripting/instal...
| j1elo wrote:
| Am I missing something cool by not looking into PowerShell
| for Linux? Anyone using it could chime in and share how it
| improves their workflow? What kind of tools does it bring to
| the table?
| Tijdreiziger wrote:
| I used PowerShell as my main shell for a few years (before
| WSL existed). My experience is that it's extremely tedious
| having to relearn every command 'the PowerShell way' if you
| already know your way around standard Unix commands (and I
| wasn't exactly a Unix guru either). When WSL dropped I
| switched and haven't looked back.
|
| The only PowerShell tool I did love was posh-git [0].
| Thankfully, someone has ported it to bash/zsh as posh-git-
| sh [1].
|
| [0] https://github.com/dahlbyk/posh-git
|
| [1] https://github.com/lyze/posh-git-sh
| torginus wrote:
| Disclaimer: I use PowerShell on Windows, I've never tried
| it on Linux, but I don't see why its advantages wouldn't
| transfer. That being said, I think it's main advantages
| are:
|
| - Typed object streams, which gives you stuff like
| autocomplete, IDE support, and generally there's no need to
| muck about with sed/awk/xargs - Very fast, it's absolutely
| fine to read a file line by line, and parse it in a script,
| whereas doing the same in bash/awk is a ton slower than
| clever use of cat/grep/wc (and a myriad of other tools) -
| Due to type information being retained, it's a lot easier
| to figure out what a given script does, without having to
| know how the output of a given tool looks like, given it's
| particular command line switches.
|
| This is just my opinion, but PowerShell is a lot more
| geared toward people like me, who only write a script once
| in a blue moon/muck about with the build scripts
| occasionally, while Bash is more geared toward veteran
| sysadmins who live and breathe this stuff.
| j1elo wrote:
| Nice summary. It leaves me wonder, though: is the
| philosophy the same as in Unix world? as in, little
| independent tools that do one and just one thing. Would
| those tools also need to be modified to add compatibility
| with the same typing system that is used by the shell?
|
| Or it follows the opposite mentality and the sell comes
| with batteries included?
|
| I'm thinking of some arbitrary example, like downloading
| a JSON and parsing it to obtain some nested sub-property.
| In Bash world you would use the shell to execute at least
| something like `wget` to do the download part, and then
| run `jq` to parse the JSON and select the desired
| property. Both of `wget` and `jq` are independent
| programs, installed separately, with their own input &
| output channels, that you combine together by using the
| shell itself.
|
| How would this work with PowerShell? (feel free to use
| some other example that might be better suited)
| [deleted]
| vips7L wrote:
| In powershell you would use built ins.
|
| To download json over rest you would use Invoke-
| RestMethod or irm.
|
| To convert json to objects you would use ConvertFrom-
| Json.
|
| To select properties from objects you would use Select-
| Object or select.
|
| Here is a concrete example that I wrote for the rustlings
| install script: https://github.com/rust-
| lang/rustlings/blob/main/install.ps1...
|
| Note that I used Invoke-WebRequest instead of irm here.
| j1elo wrote:
| And then I guess the shell itself has mechanisms to
| easily attach or register new commandlets, to allow for
| easily add custom object processing?
|
| I really like the consistency that those commands have:
| ConvertFrom-<ConverterFormat>.
|
| No built in converter for the format you need? I'm just
| speculating here, but I guess you just need to implement
| this or that Interface and there you go.
| godtoldmetodoit wrote:
| You can define your own function and use it in your
| pipeline yes. You can have your function take pipeline
| input just like the built in cmdlets.
| vips7L wrote:
| Yes you can write your own cmdlets in either C# or
| powershell that you can install via modules [0]
|
| You can also just write a function in your profile.
|
| [0] https://docs.microsoft.com/en-
| us/powershell/scripting/develo...
| naikrovek wrote:
| Powershell commands (called "commandlets" or "cmdlets")
| are little .net (or .net core) programs/methods which
| accept and return either objects or arrays of objects,
| rather than plain text.
|
| powershell offers cmdlets which let you sort and filter
| these result objects based on object property values
| rather than sorting on plain text values.
|
| Obviously when printing to stdout or stderr, THAT bit is
| plain text, but until that very last step of displaying
| in the terminal, powershell results are objects.
|
| So, that gives you a form of type safety, which isn't
| strictly possible in text-only shells. Powershell uses
| reflection to inspect the objects since the exact type of
| a response may have never been seen before. You can write
| your own cmdlets which return your own types and you can
| modify types returned by cmdlets using operators like
| 'select'. So, it's type-safe but not like everyone is
| used to. Powershell cmdlets always return objects (or
| errors, I guess), but the structure of those objects
| isn't always known until runtime. You can still use those
| never-before-seen types with the standard operators like
| sort and select, too.
|
| Powershell also offers output conversion cmdlets which
| let you output to CSV or a textual table or a list, which
| is helpful when the next step in your pipe chain is a
| tool that expects textual input or a csv file. One can
| also write their own output formatters, of course.
|
| In those ways, powershell and nushell appear to have the
| same goals. I haven't looked at nushell any more closely
| than it would take to notice this, so there may be other
| similarities I haven't noticed, yet. I'm sure there are
| many differences that I haven't noticed yet, as well.
| j1elo wrote:
| Thank you very much, it's now clearer to me how it works.
|
| Regarding the objects themselves, the way you describe
| them makes me think of Javascript objects & arrays: you
| don't need to know the exact shape of an input object, as
| long as it has the specific properties that you want to
| work on. Same for arrays: regardless of their content,
| the language allows you to use the standard ops like
| map() or find() (and it's then a matter of you providing
| adequate functions to access the contained elements)
| [deleted]
| yabones wrote:
| Powershell is a pretty neat scripting language, especially
| if you manage Windows boxes or have lots of .net stuff
| around.
|
| It's not a good interactive shell environment though. The
| commands are _way_ too verbose and the syntax feels clunky
| for keying in.
| AnIdiotOnTheNet wrote:
| I disagree. Yes, the syntax is verbose so that you get
| sensical names instead of things like 'awk' and 'grep',
| but that isn't a big deal because a) tab complete[0], and
| b) user-definable aliases.
|
| [0] tab complete works on cmdlets, switches, _and
| variables_.
| JadeNB wrote:
| > [0] tab complete works on cmdlets, switches, _and
| variables_.
|
| Isn't this how modern tab complete works everywhere? bash
| 5.1 (the shell I happen to be running right now, and
| which I mention because I think of its out-of-box tab
| completion as pretty basic) tab completes variables.
| Arnavion wrote:
| And if one misses the short incomprehensible aliases, the
| common commandlets have those by default anyway. `cat` is
| `gc`, `grep` is `sls`, `ls` is `gci`, ...
|
| Same for switches and parameters. You don't have to miss
| `rm -rf foo/`, it's just `ri -re -fo foo/`
| e12e wrote:
| I don't think so. Although, there seems to be small trend,
| especially with golang utilities - to shift from text
| toward json - or rather a "worst of both worlds" - docker
| is a prime example of this, eg: docker
| network inspect webservers -f '{{
| range.Containers}}{{.IPv4Address}}{{end}}'
|
| Once tools start down this path, I think powershell, or any
| shell built around primitives that work on tree structures,
| make more sense (ie: rather than cut, awk, grep-tools for
| printing named fields etc).
|
| Must admit, I am no big fan of ps syntax - too verbose for
| interactive use - too unfriendly for scripting..
| smackeyacky wrote:
| I use it a bit on windows servers because it integrates
| well with other microsoft tools.
|
| On linux...it seems both redundant and just plain weird for
| weirds sake. There are literally dozens of alternatives on
| linux that have a sane syntax and are likely preinstalled.
| Macha wrote:
| Powershell has some interesting ideas about passing around
| objects rather than just text.
|
| The unix way of text streams and tools to manipulate them
| are too ingrained that I haven't bothered to get in detail,
| but I hear some people are fans.
| tonyedgecombe wrote:
| If you spend all day immersed in PowerShell on Windows then
| it might make sense to leverage that familiarity on Linux.
|
| Also if you are managing Azure from Linux or macOS.
| Kipters wrote:
| I don't use it as a shell on Linux/macOS (I don't think
| it's even really supported yet), but as a scripting
| environment it's been ok: the language is sane enough, you
| can use the .NET BCL if you need to and its behavior is
| consistent across platforms.
|
| We use it for automation in our .NET codebase (which is
| being developed on both Windows and Linux) instead of bash
| scripts because of that and the fact it's preinstalled in
| the .NET SDK Docker images
| brushfoot wrote:
| It's supported on Linux. It's one of the first packages I
| install on a fresh box lately.
| loulouxiv wrote:
| What do you use it for generally ?
| anticodon wrote:
| PowerShell from Microsoft is looking too alien on Unix. Just
| looking at the syntax I already feel uncomfortable.
|
| It's hard for me to criticize it because I haven't used it,
| but it looks like it was designed by a committee and
| overdesigned. I.e. it wasn't created from the need, like
| someone at Microsoft wanted to automate his work and created
| PS to solve his problem. It looks like some boss decided:
| "They have shells, so we should have it also. But we will
| make it much cooler. So, let's gather a committee of 500 of
| our best managers and let's decide what features it should
| have".
|
| It looks artificial and inconvenient to me unlike Unix
| shells. Maybe I'm wrong. But I'm pretty sure that even syntax
| of PS makes it harder to type the commands. Unix commands are
| very short (many are 2-4 letters long), all lowercase and do
| not contain characters which are hard to type (e.g. `-`).
| skissane wrote:
| PowerShell was started by a single person, Microsoft's
| Jeffrey Snover. As the project progressed other designers
| came on board but Snover remained (and remains) as Chief
| Architect. The design-by-committee allegation isn't being
| fair to him.
|
| Part of why PowerShell may seem not quite Unix-like, is
| Snover didn't just look at Unix as an influence. Snover's
| professional background included experience with IBM
| OS/400's CL shell and OpenVMS's DCL, and his experience
| with both systems influenced PowerShell's design.
| AnIdiotOnTheNet wrote:
| The only thing I can think of in PowerShell that
| definitely seems to be "design by committee" is the whole
| ScriptExecutionPolicy nonsense.
| larodi wrote:
| Once you start using PWSH, the design decisions are so
| obvious and make so much sense, that it is obvious
| Jeffrey Snover did have vast experience with variety of
| shells and languages.
|
| The idea to tie it with .NET and COM+ on windows is the
| best a shell has ever done, though someone noted in
| another thread that it is an old idea from XEROX
| mainframes (not sure what the name was).
|
| if you want to imagine this in terms of unix/linux - it
| would be something like having all libraries' APIs at
| disposal directly from a shell that passes structured
| objects. or python's REPL being more shell-usable or JVM
| having a shell that provides access to all classes in a
| click of ENTER.
|
| major downside of pwsh is that you can feel it being
| slower than expected due to the way objects are passed
| around, but I really expect this will be solved at some
| point with future releases as PWSH as language is still
| being developed so some concepts and internal
| architecture decisions perhaps change a lot.
|
| noshell is taking this idea to a fair level, but really,
| there is a reason to do some dev/devops work in PWSH
| because it will heavily impact all future shell
| development even if eventually superseded by something
| better.
| rkeene2 wrote:
| If you want that same ability from bash, it's available
| [0]. However, it interacts with C FFI, so it's lower
| level.
|
| [0] https://github.com/taviso/ctypes.sh
| hyperpallium2 wrote:
| BTW Jeffrey Snover said every PowerShell feature was
| supported by a business case. A principled approach, I
| thought, if mercenary.
|
| But what's the "business case" for iteration,
| conditionals, addition - apart from "everyone needs
| these"? Though these probably weren't the features he was
| thinking of.
| IlliOnato wrote:
| I don't think I understand the question.
|
| You think iteration, conditionals, addition are not
| needed in shell scripts? It would be a very unusual
| position indeed.
|
| Or could it be that you are not familiar with the
| expression "business case"? (Sorry if this is off base!
| but the word "mercenary"in your post also kind of points
| this way).
|
| "Business case" has very little to do with business as
| commercial enterprise...
| 13of40 wrote:
| > They have shells, so we should have it also
|
| The thought process was more like "You can either hire a
| dude to do it by mouse in MMC or you can get someone with a
| masters in CS to do it in DCOM. We need a middle ground."
|
| Source: was in the room
| rjzzleep wrote:
| Can you elaborate?
| pjc50 wrote:
| Not OP, but: MMC = Microsoft Management Console, the
| collection of "snap in" GUI config tools for all the
| advanced features beyond Control Panel.
|
| MMC _can_ control remote computers, but I believe only
| one at a time? Unless it 's something through Group
| Policy.
|
| Now, the APIs exist to do all this remotely (DCOM), but
| good luck discovering what they are! And the minimum
| level of program you'd need to call them would be a C#
| project.
|
| So, Microsoft knew that UNIX systems had an API that was
| interactive, scriptable, discoverable, and composable,
| all the things which CMD and MMC and DCOM aren't. So they
| decided to build one. And make it object-orientated. It's
| actually pretty good for the administration use-case, but
| for more general work it feels weird. And it doesn't
| interact with text files anywhere near as good as shell
| does.
| tenebrisalietum wrote:
| Some snapins can connect to multiple servers/computers at
| once, such as the DHCP MMC snapin. Others can't, like
| Event Viewer.
|
| IMHO Microsoft went all-in on the object-oriented
| paradigm and tuned the operating system to work with C++
| ABIs and expecting administrators to use tools that use
| Microsoft or vendor provided DLLs.
| rjzzleep wrote:
| Everything you say is accurate, but it doesn't really
| relate to his claim for the reasoning behind the
| decisions behind Powershell. That's what I was referring
| to when I asked for a more detailed elaboration.
| 13of40 wrote:
| I worked in Windows Server on admin tools in the late 90s
| and 2000s, and watched the whole thing happen. I heard it
| summed up like that from Ballmer himself. I don't know
| what your alternative idea is - you think Microsoft was
| jealous of Linux and spent a hundred million dollars
| making a new shell just so they could feel proud?
| gpvos wrote:
| Same for me, but looking at nushell, I'm not ruling out
| that they'll end up with something _very_ similar to it. (I
| haven 't used Powershell much to be honest.)
| kaba0 wrote:
| I'm sorry to say this but this is a very uninformed comment
| with way too many biases without any backing.
|
| > I.e. it wasn't created from the need, like someone at
| Microsoft wanted to automate his work and created PS to
| solve his problem
|
| Interestingly enough, it is used for automating Windows
| configuration.
|
| Re last paragraph:
|
| UNIX commands are random letters that are like that due to
| historical reasons -- if you don't know one exists, you
| can't find it. And when you have to use {} in PS you are
| dealing with something you would do with awk sed with even
| more arcane syntax -- PS is pretty readable with some
| knowledge on any PL. Also, they are Verb-Noun based so you
| can get around and find commands even offline (though Noun-
| Verb would have probably been a better decision). Due to
| the fixed syntax they can be shortened very well. Also, due
| to every "command" having the same conventions, arguments
| are properly done (no tar xf or -xf or --extract), they are
| reliably autocompletable without black magic, and they are
| also autocompletable by giving enough letters to make it
| unambiguous. So while I am not particularly fond of
| Microsoft, powershell is better than bash (though frankly,
| what isn't?) in every conceivable way.
| wokwokwok wrote:
| > So while I am not particularly fond of Microsoft,
| powershell is better than bash (though frankly, what
| isn't?) in every conceivable way.
|
| There are fair criticisms to be made of bash...but this
| isn't a fair comment either; I use power shell a lot;
| I've written hundreds or thousands of lines of powershell
| glue for scripts and devops pipelines and all kinds of
| things.
|
| It's not very good.
|
| It _is_ one of those things that seems like it's a great
| idea; everything is an object, don't serialise between
| jobs, tab completion on related objects, verb-noun
| commands... it reads like a feature matrix.
|
| The reality is less ideal.
|
| It's verbose, the commands are arcane, and the verb-noun
| thing breaks down into meaningless pairs in many cases,
| particularly in the azure commands, or worse sql server
| commands.
|
| Maybe, to be fair, there is a core of elegance in there,
| but powershell displays a fundamental failure:
|
| When an application doesn't have to do the hard work of
| making a good cli, the resulting commands in powershell
| are actively user hostile.
|
| It's a pattern I've seen over and over again; and things
| like the az-cli are a tangible acknowledgment from
| Microsoft itself that the results have been substandard,
| and rejected, overwhelming, by the broader community _in
| favour_ of arguably inferior tools (eg bash).
|
| So... you might argue "network effect", but I don't buy
| it; powershell isn't friendly; not to new developers, not
| to "clicks ops" developers, not to Unix developers.
|
| It's firmly a middle ground "no one wants to use it if
| they can avoid it" product.
|
| Bash scripts, now there is literally a hell on earth...
| but bash itself? Works fine.
|
| /shrug
| brushfoot wrote:
| > It's firmly a middle ground "no one wants to use it if
| they can avoid it" product.
|
| No way, I love PowerShell. It was my first choice for the
| bulk of a B2B Windows integration product. Part of it's a
| C# desktop app; the rest is PowerShell scripts that
| customers can edit to taste.
|
| I reach for it all the time in projects. The pipeline is
| so clean to work with. Once you get used to how it
| handles collections, the cmdlets are very intuitive, and
| PowerShell Gallery has a large selection available for
| download.
|
| Objects instead of strings is big by itself, of course.
| Then you get the .NET standard library right in the shell
| to interact with them. Great for parsing dates, numbers;
| a powerful regex engine; stream manipulation; pathing
| functions; the ability to write and execute C# in the
| shell; etc.
|
| The cmdlets for data manipulation have gotten very good,
| too. The CSV cmdlets used to be unintuitive because they
| exported type data, but that's now off by default.
| `Import-Csv` and `Export-Csv` work with objects that you
| can easily manipulate with the set operations cmdlets. It
| feels very much like LINQ.
|
| Same with `Invoke-RestMethod` (`irm`) when interacting
| with APIs. It deserializes JSON into objects
| automatically. You can then easily filter or transform
| the result.
|
| There's a learning curve for sure, but once you get past
| that, it's a very good shell. I feel like it's one of the
| best things to come out of Microsoft.
| unwind wrote:
| This comment would make it into awesome-space, for me at
| least, if it had some examples of the issues you mention.
| kaba0 wrote:
| I didn't mean that PS is the ideal shell, it has plenty
| of warts (I did mention the Verb-Noun thing), and bash's
| syntax does have a good subset -- namely piping,
| redirects to a certain degree. But variable substitution,
| not having proper math support, everything is text are
| terrible and they do come up with the arguably rare, more
| complex commands. Also, having a convention that has
| quite a few edge cases where it doesn't work good may
| still be better than not having any. And the application
| not creating good cli is not shell-specific at all ---
| the linux world has it better because a good cli is
| prioritized. Even though git is often touted as having a
| terrible interface.
| anticodon wrote:
| Yes, I haven't used PowerShell. And I agree that my
| comment is uninformed.
|
| It's just that I feel uncomfortable even looking at the
| PS syntax. Maybe it's idiosyncratic. Maybe I've spent too
| many years in Unix shell.
| rjzzleep wrote:
| I've used it and I can relate to the comment. Maybe your
| assumptions are off in there, but I think the main point
| you were trying to make is that it's complicated. It's so
| complicated that you really need a repl to be able to
| work with it efficiently. It's a bit like how programming
| Java is simple if you do it in Idea or back then in
| eclipse, but in a pure editor it's impossible to remember
| all the boilerplate.
| kaba0 wrote:
| Can you write a bash one-liner that gets the free memory
| of your system? Is the awk blackmagic better than
| selecting an item of an object? Of course new things will
| be harder to write but it's a people problem not
| something inherent with PS.
| 411111111111111 wrote:
| is the _writing_ part really what we should focus on in
| scripting though?
|
| i personally would've put much more weight into the ease
| of reading and understanding the code.
|
| personally, i think that PS just came too late, so most
| people (me included) are too used to the way the unix
| shell works/feels. It would have to be just straight up
| better in all regards to displace it, but its more like a
| different flavor entirely. It however a very interesting
| take on scripting, in my mind it was more comparable to
| python repl then bash though, but i haven't really used
| it much.
| AnIdiotOnTheNet wrote:
| Wait, are you seriously trying to tell me that bash is
| more readable than PowerShell? Excuse me, but what
| alternate timeline did you accidentally stumble in from?
| 411111111111111 wrote:
| I did not say that, no.
|
| I said that a lot of people (me included) are more used
| to Unix shell scripting. If PS had been released 30yrs
| ago, things wouldve probably been different. People have
| however already become comfortable with Unix shells, so
| it needs significant improvements to convince them to
| switch the tool of choice. While PS does have
| improvements, they're not significant enough to relearn
| everything.
|
| To me, Unix scripts _are_ more readable though, this is
| simply because Ive been writing them for so many years
| now, while I barely touched any PS code.
| AnIdiotOnTheNet wrote:
| I very much disagree. There's a reason this is funny:
|
| https://xkcd.com/1168/
| jamincan wrote:
| I think bash is only readable because pretty much
| everyone is already familiar with the syntax. Given
| someone with no experience, they would probably have more
| success understanding what a Powershell script is doing.
| 411111111111111 wrote:
| > _personally, i think that PS just came too late, so
| most people (me included) are too used to the way the
| unix shell works /feels._
|
| I'm getting confused here, Isn't that literally what I
| said?
| rjzzleep wrote:
| I find cut easier to use than remembering awk syntax. So
| I get where you're coming from, but it's just a tad
| disingenuous don't you think? Especially since `free`
| `man free` is definitely easier to remember than Get-
| Whateverfunctioncall is
| vips7L wrote:
| Is it easier? Because I would expect man free to go to
| the C stdlib.h definition.
|
| You're just familiar with the former and not the latter
| currently.
| rjzzleep wrote:
| Your assumption is wrong. Why would you double down on a
| bad argument? Don't you have a linux environment to type
| man free in before making that claim?
|
| It's just an overall bad argument. I don't see how `Get-
| CimInstance -Class Win32_OperatingSystem` is in any way
| memorable
|
| https://www.google.com/search?q=man+free
| vips7L wrote:
| How is expecting man free to point to the stdlib function
| a bad argument? man malloc goes to the function so why
| shouldn't man free? How would anyone just know that the
| command free exists _without already being familiar with
| a linux environment_ ?
| reallydontask wrote:
| man free for me shows the BSD library functions manual,
| maybe it's different in Linux
| Arnavion wrote:
| It's the same on Linux, depending on what manpages you
| have installed. free(1) is the binary. free(3) and
| free(3p) are the C function.
|
| If you have more than one installed, `man` might decide
| to show the first one or it may interactively ask you to
| pick one, depending on whether it's been configured to be
| "posixly correct" or not.
| kaba0 wrote:
| Sorry for calling you out on it, I often write opinion-
| pieces without much backing as well :)
|
| I was initially very biased against PS as well, but then
| had to learn it and I found the design quite genius. At a
| time I even tried to use it as a daily driver on linux
| but my muscle memory is UNIXy, and there are a few edge
| cases that are harder in PS than in bash so I had to
| revert back. But we should strive to keep an open mind
| even about Microsoft technology :)
| user-the-name wrote:
| If somebody tried to introduce the Unix shell syntax
| today, they would be laughed out of the room. Nobody
| would be able to take something so utterly nonsensical
| seriously.
|
| The only reason anyone accepts it is that it has always
| been there. But if you actually look at it critically, it
| is hot garbage.
| lc9er wrote:
| Idiomatic Powershell is definitely verbose, but you get
| used to it (and you can disregard if you want). The
| verbosity can be used to make it more human readable, if
| done right. I use Powershell on a daily basis - the
| biggest thing that people have noted is passing objects,
| instead of text. At first it was weird, but now I find it
| really helpful. It makes it very easy to tie components
| together, without having to slice and dice text.
|
| Another great feature is named parameter support. It's so
| much easier to deal with parameters than with other
| languages I've used.
| oblio wrote:
| I'm sorry, are you a shell user? Since when ~, for example,
| is easy to type and - is hard to type? LOL.
|
| First of all your backstory is wrong, it was a 1-person
| project. Then, about the features, all those long, explicit
| commands have short versions.
|
| Secondly, I agree that Powershell feels a bit alien on
| Unix, which will probably be the main reason its adoption
| will never be amazing.
| Macha wrote:
| For a long time the Windows equivalent of ~ was
| %USERPROFILE% which was definitely harder to type than ~.
| Eventually they introduced the shortcut on Windows too.
| michael-ax wrote:
| seems nu can do a lot of otherwise horrid sed/awk/cut/etc parsing
| for bash. that is great!
| stackedinserter wrote:
| What if we added json output mode to all shell commands? Or at
| least make some wrappers that parse their unstructured text
| output into json.
|
| We would be able to use standard pipelines and jq to filter/query
| outputs, without any custom shells.
|
| Just imagine: ifconfig --json | jq '.[] |
| [.interface, .inet] | @tsv'
| dmytrish wrote:
| There is some movement in this direction: e.g. it's possible to
| do `ip -j addr` today.
| talideon wrote:
| You're not the first person to think of that. See Juniper's
| libxo: https://github.com/Juniper/libxo
|
| It's integrated into a lot of FreeBSD's command line tooling,
| and is very useful, when it's available.
| e12e wrote:
| I am with you in principle - but I still don't get the jq
| path/filter syntax I'm afraid. I think I'd vastly prefer
| map/reduce/zip commandlets...
|
| Ed: I'd say from a quick glance that I think I rather prefer
| nushell to powershell
| helsinkiandrew wrote:
| I wonder if the pipelining could be added to a regular shell to
| get its advantages - the cost for me from moving from Bash is too
| high.
|
| Basically a "cols" command on steroids - making that have some
| kind of context aware column names (I'm not sure how) and then
| support expressions would make it work in any shell.
| chubot wrote:
| That's basically what Oil's approach is. Oil is POSIX and bash
| compatible, but it also has Python-like data structures
| (recursive dicts, lists). And there's also room to add
| select/filter/sort. We need help :)
|
| https://github.com/oilshell/oil/wiki/Structured-Data-in-Oil
| mukadul wrote:
| Will fork it as nutshell
| imperialdrive wrote:
| Heck yah - Very NICE! The demo is what hooked me.
| akavel wrote:
| Could someone let me know if https://github.com/akavel/up works
| ok with it? (on Linux or Mac or WSL) I'd be grateful for
| feedback!
| gavinmckenzie wrote:
| It looks very interesting, but the first thing I noticed as a
| macOS user, is the shell has a built-in command "open" which I
| expect will conflict with the standard macOS command "open" and I
| haven't found any docs that describe how to deal with this.
| __d wrote:
| This is true of shell built-ins for eg. test too.
|
| The solution is to use the full path if you want to use the
| program, not the shell built-in.
|
| In this case, "/usr/bin/open" not "open" will get you the macOS
| utility. If you get sick of doing that, create a shell alias.
| andix wrote:
| I never really got acquainted with PowerShell. It always felt
| very clunky to me. But it exists, it's mature, it's cross
| platform and widely supported.
|
| Maybe I should give PowerShell Core a try.
| lloydatkinson wrote:
| It's basically powershell
| purplecats wrote:
| This looks pretty awesome. Wonder if it could be used with a
| command rather than as a new shell.
|
| Tangent: How is this at the top of the front page with a dozen
| upvotes and no comments? Maybe these upvotes all occurred at
| once?
| jamincan wrote:
| I will sometimes upvote something without comment if I found it
| interesting, don't really have anything useful to say myself,
| but would be interesting in seeing what other people have to
| say.
| [deleted]
| vbsteven wrote:
| You can with `-c`: $ nu -c "sys | get
| host.name" > Ubuntu
| sam0x17 wrote:
| A lot of people just upvote anything that is a GitHub repo
| because it's generally more useful than actual news
| brundolf wrote:
| It's not uncommon for people to upvote without commenting if
| they don't have anything to actually add or the post is self-
| explanatory
| Macha wrote:
| Software releases commonly get this treatment, I remember the
| comment about why there was no discussion on the actual
| contents of the change on a decently upvoted post about a
| minor release of wine, for example.
| tastroder wrote:
| This tracker was a show HN last month, looks pretty normal
| https://upvotetracker.com/post/hn/27525031
| spoiler wrote:
| On one hand I do like the idea that it's a shell since it means
| in it's nicely integrated with itself (can't think of a better
| phrase), but on the other hand it's also what's making me a bit
| reluctant to seriously consider it because I'm too used to
| fish.
|
| It would be ideal to me if it were a tool that could be piped
| into.
|
| However, that's not to say I won't at least give it a try these
| days, since I'm really curious about it.
| shric wrote:
| Kudos for writing something in rust and not appending "written in
| rust!" everywhere.
| firefly284 wrote:
| Why is everything written in rust nowadays? Apart from the
| safety it provides.
| flohofwoe wrote:
| Might just be the Baader-Meinhof effect:
|
| https://en.wikipedia.org/wiki/Frequency_illusion
| skocznymroczny wrote:
| Good package manager, broad ecosystem of packages, no header
| files, helpful compiler messages. It offers a good
| alternative to C++ for native applications.
| chalst wrote:
| Not to mention excellent support for algebraic datatypes
| and pattern matching.
| dthul wrote:
| So much this. After having encountered ADTs for the first
| time in Haskell and later on in Rust and other languages,
| any language without sum types (like Rust's enums) feels
| wholly incomplete. And the destructuring pattern matching
| is the cherry on top.
| kamray23 wrote:
| ADT and pattern matching really does it. Older languages
| certainly have their pull and can do a lot but with many
| modern coders having an interest or even education in
| higher level mathematics, easily being able to do that
| will put you way ahead of the competition. Even the
| hyper-pure Haskell now runs its own ecosystem and has
| actual systems written in it.
| aerique wrote:
| hype language du jour
|
| In the past it has been Lisp, Python, Haskell, Go, etc.
| masklinn wrote:
| > Apart from the safety it provides.
|
| Sum types (and pattern matching), first-class results,
| ownership, good performances and a rich ecosystem turn out to
| be quite nice for a general purpose langage once you've
| passed the hurdle of the borrow checker, even ignoring all
| the zero-cost abstraction stuff.
|
| Also the really solid and safe multithreading. You might
| struggle a bit getting all your ducks in a row, but past that
| you're reasonably safe from all sorts of annoying race
| conditions. And rayon is... good.
|
| Not sufficient for GUI applications where the rust experience
| remains not great, but for CLI or even TUI?
|
| I'll misquote something i recently saw on Twitter because
| it's very much my experience: "and once again I end up riir-
| ing a one-off tool I wrote in python and wonder why I didn't
| just do that from the start".
| daptaq wrote:
| There must be something else, because most of what Rust
| brings to the table is what functional languages have been
| providing for ages, just with rebranded names.
| aethertap wrote:
| In my case, I use it because it is dead simple to get a
| standalone, lean, fast, native executable (on top of the
| other functional programming features). Cargo is a huge
| part of what I love about rust.
| indemnity wrote:
| I have a great example. We have 100s of Markdown files. I
| needed a link checker with some additional validations.
| Existing tools took 10-20 minutes to run.
|
| I cooked up a Rust validator that uses the awesome
| pulldown-cmark, reqwest and rayon crates. Rayon let me do
| the CPU bits concurrently, and reqwest with streams made
| it dead simple to do the 1000s of HTTP requests with a
| decent level of concurrency. Indicatif gave me awesome
| console progress bars.
|
| And the best part, the CPU bound part runs in 90ms
| instead of minutes, and the HTTP requests finish in
| around 40 seconds, primarily limited by how fast the
| remote servers are over a VPN halfway around the world.
|
| No attempt made to optimise, .clone() and .to_owned() all
| over the place. Not a single crash or threading bug. And
| it will likely work one year from now too.
| aethertap wrote:
| Reading your comment made me realize another thing: Using
| rust often feels like the language is a successful
| attempt to take the best parts of a lot of other
| languages and put them together into a single, rational
| collection of features. Most of what's in there isn't
| new, but it all fits together well in one place so I
| don't feel like I have to make a devil's bargain for
| important features when I start out.
| jhgb wrote:
| Most good languages seem to boil down to this.
| jhgb wrote:
| Are the checks somewhat time-stable? Couldn't some of the
| checking (and network requests) be avoided by caching?
| For example by assuming that anything OK'd withing the
| last hour is still OK.
| sssilver wrote:
| That thing is runtime performance.
| Macha wrote:
| Existing functional languages had their own issues:
|
| 1. Haskell: had to deal with cabal hell
|
| 2. Scala: Java toolchain, VM startup time, dependencies
| requiring differing Scala versions.
|
| 3. F#: .NET was considered too Microsofty to be taken
| seriously for cross platform apps.
|
| 4. OCaml: "That's that weird thing used by science
| people, right?" - Even though Rust took a decent amount
| of ideas from it, it got validated by its early users
| like Mozilla and Cloudflare, so people felt safer trying
| it.
|
| 5. Lisp: I don't think I need to retell the arguments
| around Lisp. Also a lot of the things Rust touts as FP-
| inspired benefits around type systems really aren't built
| into lisp, since it's dynamically typed, these come more
| from the Haskell/Scala school.
| masklinn wrote:
| > OCaml
|
| Also as much multithreading as Python (aka only for io).
| phtrivier wrote:
| There is truth to that, the "something else" is a
| different set of trade-offs for some _other_ things that
| have usually been associated with FP languages.
|
| Rust feels like the love-child of part of ocaml (for the
| sum types), part of C (very small runtime, ability to
| generate native code, interrop with C libs, etc..), part
| of npm (package manager integrated with tooling, large
| discoverable list of libraries), etc...
|
| Borrow-checking seems a bit newer-ish - but I'm pretty
| sure there is an academic FP language that pionnered some
| of the research.
|
| No-one is planning to give Rust the medal of best-ever-
| last-ever language any time soon.
|
| And none of that is a "bad thing" (tm.)
| masklinn wrote:
| > most of what Rust brings to the table is what
| functional languages have been providing for ages
|
| In relatively familiar package & paradigm, with great
| package management (Haskell is the best of the functional
| langages there and it's a mess), and with predictable and
| excellent performances.
| hosteur wrote:
| That is like a big deal. Also speed.
| lovelyviking wrote:
| >That is like a big deal
|
| Why you think it is "a big deal"?
| kamray23 wrote:
| Why do you not? No memory leaks, no security issues
| stemming from such. No random crashes from memory misuse,
| no issues debugging the issues that exist. It's like a
| higher level language but lower. You get to do things
| your way, except when your way is fundamentally unsafe.
| The code is then easier to debug as it actually describes
| what's happening and issues are mostly algorithmic, while
| the application gets a massive boost in reliability and
| security.
|
| Security is like _the_ issue now, along with reliability.
| That 's what people need and want. Rust offers that.
| hnlmorg wrote:
| Rust isn't the only language that offers that. In fact
| most languages offer that. Even Pascal is safer than C.
| Or if we're really concerned about security then we
| should be advocating that out shells are written in Ada.
| But clearly there's more to it than that....
|
| It's also worth remembering that the biggest causes of
| RCE in shells haven't been buffer overflows. It's been
| fundamental design problems from the outset (eg Bash
| executing functions in environmental variables
| (Shellshock) and CI/CD pipelines or other programs
| forking out to the shell without sanitising user input
| nor having sufficient RBAC in place).
|
| Don't get me wrong, I have nothing against Rust. I think
| its fantastic that we're seeing diversity in the
| ecosystem. But we need to be careful not to judge a
| project simply because of its use of Rust (or choice of
| other language). The reality is soooo much more
| complicated and nuanced than is often made out in HN.
| pdpi wrote:
| Maybe we could be writing things in ADA. I don't know,
| it's a language that's been on my radar for several years
| but I haven't actually dug into it yet.
|
| That said, we need _something_ to replace C -- and Rust
| seems to be picking up momentum. Rust seems good enough a
| replacement to me, and that's enough for me to cheer it
| on.
|
| I do agree that "written in rust" isn't as big a
| guarantee of quality as people here assume though.
| hnlmorg wrote:
| We've already had languages that could replace C.
| Ironically Pascal was replaced _by_ C on home systems.
| But Rust isn 't a C replacement, it's a C++ replacement.
|
| HN talks about Rust like there was a void before it but
| there wasn't. I think it's great that the community have
| _finally_ gotten behind a safer language and I think Rust
| is a worthy candidate for the community to get behind.
| But I 'm sick of reading about Rust as if it's a silver
| bullet. HN badly needs to get past this mindset that Rust
| is the only safe language (it is not), and that programs
| are _automatically_ safer for being programmed in Rust
| (in some cases that might be true but in most cases it is
| not).
|
| I remember learning to program back in the days when
| people would mock developers for using structured control
| flow blocks because "GOTOs are good enough". While the
| Rust movement is, thankfully, the inverse of that in that
| people are questioning whether older, arcane, paradigms
| need to be disrupted, there is still a weird following
| surrounding Rust that has the same emotive worship
| without actually looking at the problems being discussed.
| People seriously suggesting everything should be written
| in Rust or harping on about the language as if its a one
| of a kind. There's plenty of domains that better suit
| other, safe, languages and there are plenty of developers
| who personally prefer using other, also safe, languages.
| Rust isn't the right tool for everything.
|
| And the fact that I've seen people advocate Rust ports of
| programs written in Haskell, OCaml and Go because "it's
| safer now it's rewritten in Rust" is a great
| demonstration for how absurd the cargo culting has
| become.
|
| My point isn't that Rust is a bad language or that people
| shouldn't be using it. Just that people need to calm down
| a little when discussing Rust. Take this case for
| instance: most shells out there these days are written in
| safe languages. The last dozen or so shells I've seen
| posted on HN been programmed in Python, LISP, Go, C# and
| Scala. It's really only the old boys like Bash and Zsh
| that are C++ applications. So Nushell isn't all that
| unique in that regard. But because its the only one out
| of a dozen that was written in Rust, it's the only shell
| what has a page of comments commending the authors for
| their choice of language. That's a little absurd don't
| you think?
| detaro wrote:
| > _it 's the only shell what has a page of comments
| commending the authors for their choice of language._
|
| There isn't "a page of comments commending the authors"
| here, so I have no clue what you are talking about? The
| main Rust discussion is in a subthread which someone
| specifically started by asking "why Rust", at which point
| you can't really fault the Rust fans for explaining why
| Rust.
| hnlmorg wrote:
| Fair point.
| kamray23 wrote:
| Rust is far from "one of a kind". There's a similar-ish
| project for C at https://ziglang.org/, and to be honest,
| there have been 20 such projects in the past, 6000 if you
| count all the total failures, I just like this one.
| hnlmorg wrote:
| That's my point :)
| pdpi wrote:
| Rust is perfectly happy to leak memory. Leaks are _not_
| considered unsafe. There was actually a bit of a
| reckoning around the 1.0 release where people widely
| assumed the language wouldn't leak, and leaks were proven
| to be safe behaviour.
| zozbot234 wrote:
| Unintentional leaks are rare in Rust, the main issue is
| around reference counting loops not being cleaned up
| automatically. Future versions of Rust might even offer
| some support for unleakable 'relevant types' (the dual to
| the existing 'affine types' where leaks are not
| considered incorrect) for better support of very
| advanced, type-directed resource/state management.
| kamray23 wrote:
| Oh? Perhaps I need to reconsider my past trust in Rust.
| In retrospect it makes sense, interop. without leaking
| memory would be damn near impossible.
|
| Still, I expect it to be very hard to do accidentally. In
| C all you need to do is have your mind blank for a
| moment. Which isn't that uncommon, especially if you're
| on crunch or something.
| pdpi wrote:
| So there's two things to talk about here.
|
| First, the language can't save you from getting the
| program semantics wrong (e.g. if you never delete an
| entry from a hashmap even after you're done with it,
| you're leaking that memory). No language can save you
| from leaks as a general concept.
|
| Second, Rust makes a very specific promise -- freedom
| from data races. Leaking resources does not actually
| break that promise, because it doesn't allow you to
| access that resource any more.
| tlamponi wrote:
| "Security bugs" are after all just a specific class of
| bugs and are still a huge nuisance in non-critical
| applications as a crash one could leverage for
| circumventing some security boundaries means most often
| just a unexplained crash for the common user, which just
| wants to use a tool in good faith.
|
| So, reducing security bugs means less crashes on weird
| input, less leaks (better resource usage), just a more
| stable tool as some classes of bugs (which may or may not
| be security relevant) are just eliminated completely -
| that's a big deal as with rust the (runtime-)cost other
| languages avoiding this is just not there (or much
| smaller).
| vbsteven wrote:
| I think Cargo doubling as both build tool and package manager
| is a big factor here. The combination of Cargo + crates.io
| makes it very easy to write some Rust code and make it
| available to anyone with Cargo on their system. Either by
| `cargo install nu` to build it from sources on crates.io or
| `cargo install` inside the git repo to build my own
| customized version. No more waiting for distro packagers to
| keep up.
|
| Putting this together makes for a nice environment to
| distribute native system tools. And in the last few years
| we've seen a wave of these tools becoming popular (ripgrep,
| bat, fzf, broot, exa and some others).
| spullara wrote:
| How are you measuring popularity?
| vbsteven wrote:
| Popularity in this context is my personal experience
| seeing these tools pop up over and over again in the
| media that I consume.
| vogon_laureate wrote:
| Thank you for listing these. I had a look at them and they
| are really useful utilities. Now the challenge is to try to
| change the muscle memory that relies on the traditional
| unix commands!
| chx wrote:
| This is insanity and hubris.
|
| "It's so easy!" yes if you have the language and tools de
| jour installed and up to date. I want none of that.
|
| It was node and npm.
|
| Then go.
|
| Now Rust and cargo.
|
| Oh, I forgot ruby.
|
| And all this needs to be up to date or things break. (And
| if you do update them then things you are actively using
| will break.)
|
| I don't need more tamagochis, in fact the less I have, the
| better.
|
| What happened to .deb and .rpm files? Especially since
| these days you can have github actions or a gitlab pipeline
| packaging for you. I can't care less what language you are
| using, don't try to force it down my throat.
| vbsteven wrote:
| I'm the parent that you replied to. In my eyes there is
| nothing wrong with .deb and .rpm files. In fact, many of
| these tools are available for download in these formats
| and some others (docker, snap, etc). And it is good that
| they do but it comes with extra work to setup the
| pipelines/builds.
|
| The concept of a language-specific package manager
| distributing not only libraries but also executables
| isn't new. Go get, ruby bundler, python pip, cargo and
| npm all have this feature.
|
| I was originally answering a question about why we
| suddenly see all these "written in Rust" tools pop up. I
| think that is partly because Cargo provides this easier
| way to distribute native code to users on various
| platforms, without jumping through additional hoops like
| building a .deb, and setting up an apt repository.
|
| Sometimes you just want to get some code out there into
| the world, and if the language ecosystem you are in
| provides easy publishing tools, why not use them for the
| first releases? And if later your tool evolves and
| becomes popular, the additional packaging for wider
| distribution can be added.
| stevenhuang wrote:
| Why don't you download the native binaries then?
|
| Rust isn't an interpreted language, you only need the
| rust toolchain if you want to build from source.
| vkoskiv wrote:
| Binary releases seem uncommon from my perspective. Every
| time I go to install a piece of software written in Rust
| from homebrew, it invariably starts installing some
| massive Rust toolchain as a dependency, at which point I
| give up and move on. Maybe it's a case of the packagers
| taking a lazy route or something, or maybe there is a
| reason for depending on cargo. I have no idea.
| Macha wrote:
| Isn't homebrew specifically supposed to build from
| source? e.g. the example on the homepage of a recipe is
| running ./configure && make on wget.
|
| The fact that you installed the XCode CLI tools for that
| wget example to work when you first installed homebrew
| because homebrew itself requires it, and you only get
| Cargo the first time you get a rust dependency seems to
| be what you're really complaining about.
| indemnity wrote:
| Do you have some specific examples?
|
| E.g. ripgrep is packaged on most operating systems I have
| used, along with exa, and a few other Rust utils I use.
|
| I certainly do not use Cargo to install them.
| pdpi wrote:
| Ease of use and familiarity are different things. Tooling
| around rust really _is_ easy, when the alternatives (for
| equivalent languages) are CMake, autotools, and the like.
|
| As it stands, I can brew install ripgrep and it just
| works. I don't need to know it's written it rust. If, for
| some reason, homebrew (or whatever other package manager)
| is lagging behind and I need a new release _now_ , cargo
| install is a much easier alternative compared to, again,
| other tools built in equivalent languages
| xpe wrote:
| Indeed. Thank for you stating this so clearly.
|
| The "ease of use" and "familiarity" distinction reminds
| me of talks by people such as Rich Hickey who distinguish
| "simple" and "easy":
|
| https://www.infoq.com/presentations/Simple-Made-Easy/
|
| > Rich Hickey emphasizes simplicity's virtues over
| easiness', showing that while many choose easiness they
| may end up with complexity, and the better way is to
| choose easiness along the simplicity path.
| fauigerzigerk wrote:
| I agree that it's not ideal, but unfortunately bad
| decisions by Linux distributions and package maintainers
| have trained me as a user to avoid the package managers
| if I want up to date software with predictable and
| documented defaults.
| chriswarbo wrote:
| > What happened to .deb and .rpm files?
|
| The problem with those is they require global
| consistency. If one package needs libfoo-1.1 (or at least
| _claims_ to), but something else needs libfoo-1.2+, we
| can 't install both packages. It doesn't take long (e.g.
| 6 months to a year) before distro updates break one-off
| packages.
|
| I think some people try hacking around this by installing
| multiple operating systems in a pile containers, but that
| sounds awful.
|
| My preferred solution these days is Nix, which I think of
| as a glorified alternative/wrapper for Make: it doesn't
| care about language, "packages" can usually be defined
| using normal bash commands, and it doesn't require global
| consistency (different versions of things can exist side
| by side, seen only by packages which depend on them).
| aldanor wrote:
| Ruby requires an interpreter at runtime. JavaScript too.
| Rust produces standalone binaries. So no, "things don't
| break" and you only compile things once.
|
| // I can't care less about deb or rpm files so don't try
| to force that down my throat.
| pjmlp wrote:
| It is Gentoo all over again.
| hnlmorg wrote:
| There's no win/win scenario when comparing libraries to
| static binaries. On the one hand, static binaries are
| more user friendly. But they remove the responsibility
| for keeping your OS secure away from the OS/distro
| maintainers.
|
| For example, if a vulnerability is found in a create, you
| then have to hope that every maintainer who manages a
| Rust project that imports said create diligently pushes
| out newer binaries quickly. You then have multiple
| applications that need to be updated rather than one
| library.
|
| This may well be a future problem we'll end up reading
| more about as Rust, Go and others become more embedded in
| our base Linux / macOS / etc install.
| j1elo wrote:
| 100% agree. I find it very funny, but in a sarcastic and
| totally wrong way, when a project's README has an
| _Install_ section that reads: Run "cargo
| install myProject"
|
| I know Rust, so Cargo is not alien to me. But come on,
| you _know_ that your install instructions are a bit
| shitty.
|
| Please, choose a target distro, then test your
| instructions in a clean Docker container. THEN you can
| sit down knowing you wrote proper guidance for users.
|
| EDIT because this comment is being misunderstood: I meant
| that you should make sure your instructions work as-is
| from a clean installation of your intended distro(s),
| _regardless of how you prefer to do so_ ; using a Docker
| container is just my preferred method, but you can also
| do a clean VM or whatever else, as long as you don't
| assume anything beyond a default installed system.
| [deleted]
| qmmmur wrote:
| Hold on, do you not see the insane contradiction of not
| wanting to rely on having cargo installed but requiring
| something is deployable and tested in a docker container?
| What?!
| mouldysammich wrote:
| If its deployable and tested in a docker container its
| much easier to generate user images, it takes the onus
| away from the user and the developer can just put it on
| the aur/publish a deb
| j1elo wrote:
| No, you misunderstood. I meant that if you're going to
| document a block of command-line instructions, you should
| first make sure those commands work as-is in a clean
| system.
|
| A very easy way to do this (for me anyways) is using a
| Docker container. I use this method to test all of my
| documented commands. But there are other ways, of course,
| like using a clean VM. Regardless, just test the commands
| without assuming the customized state of your own
| workstation!
|
| The point is that if I follow the hypothetical
| instructions of running "cargo install something", the
| result will probably be "cargo: command not found". When
| you test this in a clean system and find this error
| message, this places on you the burden of depending on
| Cargo, so the least you should do is to make sure "cargo"
| will work for the user who is reading your docs. At a
| minimum, you should link to somewhere that explains how
| to install Cargo.
|
| tldr: you should make sure your instructions work as-is
| from a clean installation of your intended distro(s),
| regardless of how you prefer to do so.
| qmmmur wrote:
| You're telling me that people who want to replace a
| command-line utility are the same people who can't
| install a toolchain (or just download a binary and put it
| in their path)?
| hnlmorg wrote:
| As someone who authors another shells (coincidentally
| similar to nushell) I can tell you that you'd be
| surprised at some of the bug reports you get.
|
| Frankly I prefer the 10,000 approach suggested by XKCD:
| https://xkcd.com/1053/
| j1elo wrote:
| As a single-sample statistic I can share with you, I like
| to think I'm a well seasoned C/C++ developer, and have
| experience with all sorts of relatively low-level
| technical stuff and a good grasp on the internals of how
| things (like e.g. the kernel) work.
|
| Yet I got confused the first time ever some README told
| me to run "npm install blah". WTF is NPM? I didn't care,
| really, I just wanted to use blah. Conversely, later I
| worked with Node devs who would not know where to even
| start if I asked them to install a C++ toolchain.
|
| The point is don't assume too much about the background
| of the people reading your instructions. They don't have
| in their heads the same stuff you take for granted.
| qmmmur wrote:
| There was a time that I didn't know what npm is (I'm not
| even remotely a web developer). So I used my computer to
| do some basic research.
| j1elo wrote:
| Don't focus on the specifics, consider the NPM thing an
| analogy for any other piece of software.
|
| I've found instances where some documentation
| instructions pointed to run Maven, and the commands
| worked in their machine because Maven is highly dependent
| on customizations and local cache. But it failed in other
| machines that didn't have this parameter configured, or
| that package version cached locally. And trust me, Maven
| can be _very_ obtuse and hard to troubleshoot, too much
| implicit magic happening.
|
| Testing in a clean container or VM would have raised
| those issues before the readme was written and published.
| Hence my point stands, testing commands in a clean system
| is akin to testing a web page in a private tab, to
| prevent any previous local state polluting the test.
| qmmmur wrote:
| Testing in a clean container tests deploying in a clean
| container. For me, I run a computer :) Maven sounds like
| a nightmare tbh so I can understand that that specific
| piece of software has warts. That said, a good piece of
| package management software will be relatively agnostic
| to where its run and have a dependable set of behaviours.
| I much prefer that to a world where every bit of software
| is run on any conceivable combination of OS and hardware.
| What an absolute drain on brain space and creative
| effort!
| andrewzah wrote:
| Many of the popular rust cli tools like ripgrep, exa,
| delta, etc -do- have package manager install options.
|
| How dare people writing cli tools not package them
| conveniently for my distro. The horror of using cargo
| instead of cloning the source and praying make/meson/etc
| works.
|
| Feel free to package and maintain these tools yourself
| for your distro if you want.
| CJefferson wrote:
| The problem with .deb and .rpm is your dependencies, some
| things aren't packaged, you end up having to build
| separate packages for each major Debian and redhat
| release to link against the correct dependency version.
|
| I'd love that to all be "one-command automated", but I
| haven't seen such a thing, unlike cargo, which I do find
| I can be productive with after a one page tutorial.
| Macha wrote:
| You happen to have cmake or autotools installed, others
| happen to have cargo installed.
|
| Once cargo/cmake/autotools/make/npm/mvn/setup.py/whatever
| runs, the process of taking the output and packaging it
| for your preferred distro is the same.
|
| There's more work involved if you want a distro to
| actually pick it up and include it in their repos around
| not using static linking, but if you're asking for a
| .deb/.rpm on github actions, that's not needed.
| kstenerud wrote:
| "What have the Romans ever done for us?"
|
| https://youtu.be/djZkTnJnLR0?t=56
| wraptile wrote:
| Seems like low level programmers finally getting an
| enjoyable, modern, free language and are getting a bit loose
| with it!
| Macha wrote:
| Also high level programmers getting something more
| performant and that doesn't require a runtime but still has
| a lot of ergonomics they're used to.
| 29athrowaway wrote:
| Backwards compatibility can be a heavy burden for a
| programming language. C++ could be a much simpler, ergonomic
| language by eliminating features and idioms that are no
| longer convenient to use.
|
| Achieving mastery in C++ requires a lot of work. C++ projects
| require a coding standard. The decision space you have when
| working in C++ is much larger than when working with Rust due
| to the proliferation of language idioms.
|
| Rust in the other hand, as a newer language, can benefit from
| the experiences working with languages such as C++, and
| provide a better experience right from the beginning. In
| fact, Rust was created by Mozilla as a response to the
| shortcomings they perceived in C++.
| pjmlp wrote:
| I just hope that Rust with 40 years of backwards
| compatibility feels better than C++ today.
| pdpi wrote:
| 40 years is a long time, so the experience will almost
| certainly degrade a fair bit. The notion of editions in
| rust makes allowances for breaking changes while still
| keeping backwards compatibility, I'm very curious to see
| whether the problems that solves outweigh the complexity
| in the compiler.
| pjmlp wrote:
| I am not convinced that editions are much better than
| language version switches.
|
| They only work in the ideal case that whole dependencies
| are available as source code, the same compiler is used
| for the whole compilation process and for light syntactic
| changes.
|
| In fact for _IntoIterator_ , a small fix to the editions
| was made, https://blog.rust-
| lang.org/2021/05/11/edition-2021.html
|
| With 40 years of history, several Rust compilers in
| production, corporations shipping binary crates, expect
| the editions to be as effective as ISO/ECMA language
| editions.
| steveklabnik wrote:
| Two out of three of those things have nothing to do with
| editions. The final one is basically saying "you can't
| make huge changes," and I'm not sure how that's a
| criticism of the possibility of "in 40 years there will
| be too many changes."
| steveklabnik wrote:
| The design of editions is such to specifically reduce
| implementation complexity in the compiler, for this
| reason. The majority of the compiler is edition-agnostic.
|
| It's not the only reason, but it's a big one.
| pdpi wrote:
| Could you expand upon this?
|
| My specific concern there is that, while the compiler
| frontend for any one given edition becomes individually
| simpler, the whole compiler becomes a bit more
| complicated, and things like IntoIterator, which pjmlp
| mentioned elsewhere, imply changes across several
| editions.
|
| This is not a major problem when editions means {2015,
| 2018, 2021}, but in a world where we also have 2024,
| 2027, ... editions, this becomes increasingly tricky.
| steveklabnik wrote:
| The Rust compiler is roughly "parse -> AST -> HIR -> MIR
| -> LLVM IR -> binary." I forget _exactly_ where editions
| are erased (and I'm on my phone so it's hard to check),
| but for sure it's gone by the time MIR exists, which is
| where things like the borrow checker operates. Edition
| based changes only affect the very front end of the
| compiler, basically. This is a necessary requirement of
| how editions work. For example, it is part of the
| interoperability story; because the main representation
| is edition agnostic, interop between crates in different
| editions is not an issue.
|
| ... I don't know how to say this truly politely, but
| let's just say I've had a few conversations with pjmlp
| about editions, and I would take the things he says on
| this topic with a large grain of salt.
| pjmlp wrote:
| When Rust editions reach about 5 in the wild, feel free
| to prove me wrong by mixing binary crates compiled with
| two Rust compilers, mixing three editions into the same
| executable.
|
| You can also unpolitelly tell me how it will be any
| different from /std=language for any practical purposes.
| steveklabnik wrote:
| Again, the ABI issue has nothing to do with editions. You
| can already build a binary today with three editions
| (though I forget if 2021 has any actual changes
| implemented yet) in the same executable. Part of the
| reason I said what I said is that every time we have this
| conversation you say you want to see how it plays out in
| practice, and we have shown you how multi-edition
| projects work, and how you can try it today, and you keep
| not listening. It's FUD at this point.
|
| It is different because those are frozen, editions are
| not (though in practice editions other than 2015 will
| rarely change). They make no guarantees about interop,
| and my understanding is that it might work, but isn't
| guaranteed. If you have sources to the contrary I'd love
| to see them!
| pjmlp wrote:
| Which is basically the same thing as /std=language, when
| applied to different translation units.
| pornel wrote:
| There is the similarity that the editions don't really
| matter for ABI, but otherwise editions are substantially
| different from the std switch.
|
| C/C++ std switches freeze the entire language and disable
| newer features. Editions don't. Rust 2015 edition isn't
| an old version of Rust. It's the latest version of Rust,
| except it allows `async` as an identifier.
|
| Editions don't really have an equivalent in C, but
| they're closer to being like trigraphs than the std
| compilation switch.
| [deleted]
| baby wrote:
| It's the new C/C++ but also you can write Rust like you're
| writing Golang.
| junon wrote:
| None of that sounds appealing on its own.
|
| Ready for the downvote wave. :D
| pdpi wrote:
| This is a thread about a shell. That's very much the sort
| of project that is typically written in C, and also the
| sort of project that _really_ benefits from being written
| in something safer.
|
| It's fine if writing systems languages doesn't appeal to
| you, but they fulfil an important niche in. V8, Hotspot,
| Cpython all have to be written in _something_.
| junon wrote:
| You assumed a lot about me from one sentence. This is why
| people dislike the rust evangelism.
| IshKebab wrote:
| It's a fast compiled language with a great type system and a
| sane build system. There aren't a lot of alternatives with
| those properties.
|
| I'd say the closest are Go, which doesn't have remotely as
| good a type system, Typescript which isn't compiled and isn't
| quite as fast or nice.
| cube2222 wrote:
| Most of the answers here omit this, and it's a very important
| point for hobby open source projects - Rust is just very fun
| to write.
| Macha wrote:
| I write a lot of personal small utilities in Rust these days:
| The tooling is more modern than C++, it's more consistent
| cross platform, and it doesn't suffer the VM startup time of
| Python, which I would have used previously.
| bmlzootown wrote:
| It's the new "I use Arch btw". Genuinely kind of tired of it
| already.
| iFreilicht wrote:
| Meh, not really. Something being written in Rust is a feature
| to me.
| geodel wrote:
| Thanks for letting us know :)
| est wrote:
| That brings a WMI vibe.
| silentguy wrote:
| What's WMI? Google search says https://docs.microsoft.com/en-
| us/windows/win32/wmisdk/wmi-st... but I doubt you were talking
| about that.
| ofiryanai wrote:
| On top of the nice approach to structured output with pipelines,
| the "cross-OS first" approach is amazing! Very cool to use a
| modern shell that can fit both Windows and Unix by design (and
| not through WSL), hell I'm going to try to introduce it to my
| small company as a standard tool. Hope it's not in a too immature
| stage, however it looks very shining and promising considering
| the enthusiast contributors community. I'm in
| thefunnyman wrote:
| Funny enough, the new PowerShell fits this description too now
| that it's packaged for Linux.
| luke2m wrote:
| I use fish for general use, but still write all my scripts with
| bash. It has worked very well for me.
| sime2009 wrote:
| I played with it recently. The interactive part is limited at the
| moment, but I really like the idea of having operations like
| sorting and filtering separate from the tools which produce the
| data. Having these things consistent and available everywhere is
| a huge cognitive win. I can finally sort and filter `ls` output
| without having to read the man page. :) "Querying" data feels a
| lot like SQL in that respect.
| bawolff wrote:
| Were you not able to before? ls | grep foo | sort is hardly
| something people normally read the man page for.
| [deleted]
| rnestler wrote:
| This isn't the way I'd sort ls output by date or whatever
| field. I'd use `ls -l --sort=date` which I guess is what the
| GP meant with having every tool do their own sorting by
| field.
|
| In nushell one can just do `ls | sort-by size`
| sime2009 wrote:
| Yes, that is what I mean.
|
| I also like that nushell's table oriented approach displays
| the column names, and you just use those names for the
| `sort` command or `where` command etc.
| bawolff wrote:
| Ah, fair enough. I misunderstood the parent.
| kaba0 wrote:
| Now sort by filesize
| rkeene2 wrote:
| File size or file length ?
| xiaq wrote:
| Shameless plug: if you're interested in nushell, you might also
| be interested in Elvish: https://elv.sh
|
| (And the various other new shells, documented by the author of
| another new shell, Oil:
| https://github.com/oilshell/oil/wiki/Alternative-Shells)
| eatonphil wrote:
| It's such a huge pain to set up bash on windows (it worked fine,
| very easy on one laptop but I cannot get bash or wsl working on
| another newer laptop) that I wrote a very basic wrapper for shell
| scripts that will transform arguments of Linux user land (like
| cp, mv, rm) to their windows equivalent. This way all you need is
| python and your "bash" scripts can just work. Sorta. There are a
| lot of edge cases. But at least it works enough that I can stop
| trying to figure out how to install bash on windows or what's
| wrong with my laptop.
| mkl wrote:
| What was the problem with WSL? It's been trivial to install on
| every machine I've tried: work, personal, old, new, upgraded
| from Windows 7, local account, Microsoft account, etc.
| eatonphil wrote:
| Yes I had that experience until this one laptop, ironically
| it's a surface laptop. Most likely I screwed some setting up
| but now no tutorial for bash in windows or wsl works anymore
| and I have no idea how to work around.
| Bayart wrote:
| I had problems with WSL on my newer laptop, and it all came
| down to disabling Secure Boot.
| eatonphil wrote:
| Oh, thanks for sharing. Maybe I'll try that.
| hans1729 wrote:
| I installed wsl on like 10 machines, including "newer laptops",
| and never had problems with the setup. Instead of solving your
| actual problem you created a whole new problem domain, that
| seems... not like the way to go
| eatonphil wrote:
| The "domain" I care about is for basic build scripts to work
| on Windows and Linux. Whichever way gets me back to regular
| work is the best way! I do not have the experience to debug
| when BoW or WSL do not work unfortunately.
| cerved wrote:
| while it can be a pain to deal with windows quirks, writing
| a wrapper script to deal with low level file IO stuff
| sounds like a good way to open a whole can of worms and
| irrevocably mess up your whole system
| simonjgreen wrote:
| On the face of it this looks like powershell
| debacle wrote:
| This seems very similar to powershell, with far better syntax.
| xolve wrote:
| Its not as yet feature complete but has come a long way from its
| earlier beginnings. I have been using it on Windows and being
| native and close to UNIX shells really helps my workflow.
|
| The inbuilt commands and structured philosophy is a great
| approach.
| moocowtruck wrote:
| "A nu type of shell"
| jpz wrote:
| First 60 second impression - this looks like powershell with not-
| insane syntax. Looks quite revolutionary, it breaks the
| traditional paradigm for UNIX shells and appears to artfully
| refine the good concepts in Powershell (which seem to be let down
| severely - in my opinion - by UX issues.)
| alkonaut wrote:
| What's wrong with the powershell syntax? The long names? Those
| are optional. I find the idea of short names (for interactive)
| AND the option of long names very good. Many of these aliases
| are similar to unix commands (e.g. "cat" instead of Get-Content
| or "ls" instead of Get-Childitem).
| arupy wrote:
| I use this in combination with fish shell and it's been working
| really well. I can just switch over to `nu` when the task merits;
| no need to replace my current shell. I can also just run a one-
| off line like this. nu -c "ls | where size >
| 10b"
| augstein wrote:
| How does it compare to fish shell (especially fish's great
| autocompletion), e.g. why are you not switching completely?
| arupy wrote:
| nu is still in its infancy, and currently lacks critical
| features of other shells, which is why I haven't switched
| completely.
|
| As for the future, perhaps a bit brazen, but I'm confident
| that other shells will introduce the core feature of nu in
| the near future to stay competitive. I can see fish having a
| "||" operator and rewrites of a few gnu functions to achieve
| what nu does natively.
| xpe wrote:
| I see the value proposition of nushell. I'm wondering if I
| should also try fish.
|
| May I ask if you switched to fish from zsh? What motivated your
| change?
|
| Background: I invested some time not too long ago to read zsh
| docs in detail and customize my own configuration (e.g. instead
| of using oh-my-zsh). Since then, I've been quite happy with
| zsh. That said, I'm also open to switching to fish and/or
| nushell based on recommendations.
| arupy wrote:
| I didn't switch from zsh, but from bash, to fish, primarily
| because bash was occasionally a bit clunky to use, and there
| were a lot of things that could be optimized in a modern
| environment. I settled on fish because it suited what I was
| looking for: an ergonomic shell that worked well out-of-the-
| box. Paired with strong community support, clean scripting
| syntax, and a wide ecosystem, it makes for a really enjoyable
| shell experience. I haven't tried zsh, so I can't compare the
| two.
|
| I'm happy with fish, and I don't see much benefit to
| switching to nu. nu is exceptionally good at one thing:
| working with data, but lacks features in other areas (auto-
| completion, scripting, etc.). With time, I can see these
| features being implemented, but I think they'll be re-
| inventing the wheel in a lot of areas that other shells are
| already good at.
| sahkopoyta wrote:
| > what motivated your change?
|
| didn't switch from zsh but bash, did it because wanted a bit
| more features at shell without additional configuration
| [deleted]
| xpe wrote:
| The _philosophy_ section is the most important aspect, in my
| opinion, because I want to know _why_ I should switch. In other
| words, show me a better future, and then I 'm more likely to try
| it out.
|
| > Philosophy
|
| > Nu draws inspiration from projects like PowerShell, functional
| programming languages, and modern CLI tools. Rather than thinking
| of files and services as raw streams of text, Nu looks at each
| input as something with structure. For example, when you list the
| contents of a directory, what you get back is a table of rows,
| where each row represents an item in that directory. These values
| can be piped through a series of steps, in a series of commands
| called a 'pipeline'.
| calltrak wrote:
| Found this handy git cheat-sheet https://picc.io/p/xM2wenl.png
___________________________________________________________________
(page generated 2021-06-16 23:02 UTC)