Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fish shell 3.0

github.com

Post reply on HN
Print view View original

191–200 of 227 posts

Re: Fish shell 3.0

#191

Post by brendyn »

barrkel wrote: post #54
CJefferson wrote: post #16

The one thing I miss most in fish is subshells, because I love writing things like ( (cd $dir && ./run_prog && cd PKG && ./do_stuff) & ), to run a series of things in the background. Is there any way to do something similar in fish?

I also do that, often with loops. for ((i=0;i out-$i.log 2>&1 ) & done Can be anything from image processing, video transcoding, file decompression, file system analysis - anything I think may complete faster with some concurrency.

Something like this should do the same thing, I think?:

seq 0 3 | parallel "./ad-hoc-operation > out-{}.log"

https://www.gnu.org/software/parallel/

Re: Fish shell 3.0

#192

Post by garmaine »

nightfly wrote: post #186
zorked wrote: post #44

Earlier quoted context omitted.

That reminds me of the very specific nag messages I get from Python 3 when I don't write parens around parameters for print... do what I want already.

In Python 3 there was an explicit decision not to support print as a statement, and rather as a function call.

You missed the point... that decision should have been made.

Re: Fish shell 3.0

#193

Post by int_19h »

thaumasiotes wrote: post #183
StavrosK wrote: post #145

Earlier quoted context omitted.

But then you no longer get back 10-1 elements, you get back 10-1+1.

So what? You're going to have off-by-one errors no matter what convention you adopt. Python glosses over it by providing the alternative syntax x[-1] for what you would otherwise have to write as x[len(x)-1]. But it's at least as valid to provide alternative syntax for inclusive ranges. And logically, if the first element of x is x[0], the last element should be x[-0], not x[-1]. Half-open intervals are appropriate w…

One thing I would add - using negative indices to index from end is a bad idea in general, because you may inadvertently end up with a negative index as a result of a calculation that you expected to always be positive - and then instead of an out-of-bounds error, you get silent wrong behavior.

IMO, it's better to have dedicated syntax for index-from-end, as part of the range syntax. Again, Nim does that: x[0..^1] (although unfortunately they didn't make it symmetric).

Re: Fish shell 3.0

#194

Post by thaumasiotes »

int_19h wrote: post #193
thaumasiotes wrote: post #183

Earlier quoted context omitted.

So what? You're going to have off-by-one errors no matter what convention you adopt. Python glosses over it by providing the alternative syntax x[-1] for what you would otherwise have to write as x[len(x)-1]. But it's at least as valid to provide alternative syntax for inclusive ranges. And logically, if the first element of x is x[0], the last element should be x[-0], not x[-1]. Half-open intervals are appropriate w…

One thing I would add - using negative indices to index from end is a bad idea in general, because you may inadvertently end up with a negative index as a result of a calculation that you expected to always be positive - and then instead of an out-of-bounds error, you get silent wrong behavior. IMO, it's better to have dedicated syntax for index-from-end, as part of the range syntax. Again, Nim does that: x[0..^1] (a…

> IMO, it's better to have dedicated syntax for index-from-end, as part of the range syntax.

This is true, and note that my suggestion requires it -- the only way to distinguish x[-0] from x[0] is to have the parser do it; -0 and 0 are the same number.

Re: Fish shell 3.0

#195

Post by korm »

joshschreuder wrote: post #152

Is there anything remotely like this on Windows? I use Cmder / Conemu now but it doesn't seem to have even 10% of the features of a fully fledged shell like this.

Oh-my-posh + a few custom scripts for better autocomplete that I found here and there. Wasn't very easy to configure and it's still nowhere near my fish shell, but at least it's much better than plain powershell.

Re: Fish shell 3.0

#196

Post by darkpuma »

ridiculous_fish wrote: post #173
darkpuma wrote: post #155

Earlier quoted context omitted.

>The principle of "no surprises" Is violated by this: > mpv https://www.youtube.com/watch?v=LBoF1e5YDdQ fish: No matches for wildcard 'https://www.youtube.com/watch?v=LBoF1e5YDdQ'. See `help expand`. mpv https://www.youtube.com/watch?v=LBoF1e5YDdQ ^ Particularly for software that sells itself as user friendly. The carrot doesn't even point at the wildcard! I am very far from the first person to raise this issue with…

Your proposed remedy is for the shell to insert something different than what the user inputs. That is much more surprising. No program works that way.

No program other than a shell requires that a URL copied out of your browser's address bar be escaped. Users may not be accustomed to a program escaping or quoting text they paste, but they're also definitely not accustomed to escaping or quoting strings manually.

Re: Fish shell 3.0

#197

Post by darkpuma »

shhsshs wrote: post #175
darkpuma wrote: post #155

Earlier quoted context omitted.

>The principle of "no surprises" Is violated by this: > mpv https://www.youtube.com/watch?v=LBoF1e5YDdQ fish: No matches for wildcard 'https://www.youtube.com/watch?v=LBoF1e5YDdQ'. See `help expand`. mpv https://www.youtube.com/watch?v=LBoF1e5YDdQ ^ Particularly for software that sells itself as user friendly. The carrot doesn't even point at the wildcard! I am very far from the first person to raise this issue with…

That is not surprising in any way. It is very clear and defined that a question mark is a wildcard, and will be expanded. If you want a literal string, define it as such with a single quote.

>"It is very clear and defined that a question mark is a wildcard"

To experienced command line jockeys like you or I, sure. To the inexperienced user, knowledge of the ? wildcard is far from given. ? is esoteric enough that fish has apparently decided to deprecate it completely. fish's error message does not indicated that the wildcard in question was ?, nor does it point to wildcard, it only points to the token that contained the wildcard with no indication of which character it was.

That's not the user friendly experience fish advertises.

Re: Fish shell 3.0

#198

Post by yoklov »

jhardy54 wrote: post #96
StavrosK wrote: post #75

Earlier quoted context omitted.

The fact that it doesn't support your particular preferred syntax doesn't mean it's not production-ready.

> your particular preferred syntax I think it's called POSIX.

It's still not POSIX compatible, deliberately.

Re: Fish shell 3.0

#199

Post by zapzupnz »

doubleunplussed wrote: post #165
thiagowfx wrote: post #99

Earlier quoted context omitted.

Adding the usual disclaimer that yay is an AUR helper and thus not officially supported by Arch. Arch users are advised to read https://wiki.archlinux.org/index.php/Arch_User_Repository instead. If you know what you're doing, of course using yay should be fine as well.

It should be noted that adding a PPA is equally unsupported, so in both cases you're trusting a third party. Despite all the disclaimers (or perhaps because of them), the AUR is IMHO one of the more safe and well-thought-out ways of including third-party stuff. It's relatively simple to verify that the package is installing what it says it is, because you can check the PKGBUILD file, which is short and simple to read…

`dpkg -L filename.deb` provides a list of files to be installed.

Re: Fish shell 3.0

#200

Post by Groxx »

naniwaduni wrote: post #164
Groxx wrote: post #114

Earlier quoted context omitted.

sometimes I wonder if "native" support for regexes would help this, or if it would just be another instance of https://xkcd.com/1171 regexes describe this sort of thing quite concisely and IMO a fair bit more readably than e.g. bash's string replacement syntax, which looks like "${var#"${var%%[![:space:]]*}"}" when you want to do the equivalent of s/^\s*(.*?)\s*$/\1/

It wouldn't even be another standard; it'd just be another incompatible implementation with its own quirks to be worked around.

yeah, the wide variance in regex engines would definitely not be a positive quality :|
Post reply on HN