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

Why Create a New Unix Shell?

oilshell.org

Post reply on HN
Print view View original

111–120 of 298 posts

Re: Why Create a New Unix Shell?

#111

Post by kevin_thibedeau »

dflock wrote: post #92
Osiris wrote: post #73

Earlier quoted context omitted.

fish-shell is the first thing I install on any *nix box I work on, including macOS, VPS servers, desktop (Ubuntu), and even Windows Subsystem for Linux. The feature I use the most is automatic history search by typing part of a command and hitting UP to search the history. I also find the scripting language more straight-forward.

> The feature I use the most is automatic history search by typing part of a command and hitting UP to search the history. This is available in bash/sh by setting this in your ~/.inputrc file: "\e[A": history-search-backward "\e[B": history-search-forward "\e[C": forward-char "\e[D": backward-char

Or just use ctrl-R et al.

Re: Why Create a New Unix Shell?

#112

Post by pbhjpbhj »

badminton1 wrote: post #26
yjftsjthsd-h wrote: post #22

Earlier quoted context omitted.

> linters for shell languages Obligatory in case anyone hasn't seen it: https://www.shellcheck.net/ Works as a web app or local tool.

Please note that copying and pasting commands from a web browser into a terminal can result in malicious code being executed. A good idea to double check using a text editor. http://thejh.net/misc/website-terminal-copy-paste

Sounds like sandboxing of pasted code until confirmation would be a good feature for a new shell ...

Re: Why Create a New Unix Shell?

#113

Post by toyg »

kemayo wrote: post #40
chubot wrote: post #24

Earlier quoted context omitted.

(author here) Hm I've tried fish, and it seems very nice for interactive use. However I don't see it being used AT ALL for the cloud/linux use case? Those are the cases where you tend to get 1000+ lines of shell scripts. For example, I mention Kubernetes/Docker/Chef, and I've never seen fish in that space. I also don't know of any Linux distro that uses fish as their foundation -- they all appear to use a POSIX shell…

It's an entrenched network effect. There's a lot of existing scripts written targeting POSIX shells, and there's an incentive to have all your distro maintenance scripts written in one language if possible. If you want to switch your existing distro scripts to fish, you need to rewrite a lot of stuff. If you want to start a new distro, "it's written in fish!" isn't a terribly compelling selling point, since I don't t…

> I don't think anyone is actively picking distros based on their tooling language.

I would use the crap out of a Linux distribution built in python.

Re: Why Create a New Unix Shell?

#114

Post by XorNot »

The pain of "not quite bash" ultimately is what put me off xonsh as my daily shell. Also losing it whenever I SSH'd somewhere.

The latter problem could probably be solved with a wrapper which would pipe and execute the shell (or a bytecode interpreter ala shuttle?) automatically - but I've seen no alternative shell project take this part seriously for the problem space.

Re: Why Create a New Unix Shell?

#115

Post by kevin_thibedeau »

dfox wrote: post #11
castis wrote: post #4

I see that this person has opted not to use python 3 because it is 'less-suited to shell-like problems' than python 2. In an effort to understand the reasons for actively choosing against 3, does anyone know what problems those would be?

One reason I can see is that while Python 3's unicode handling is saner for most of usecases it does not work the way one would expect in unix shell.

Python isn't going to reconfigure an ASCII shell on your behalf. It's up to you to enable a Unicode locale and then PY3 just works.

Re: Why Create a New Unix Shell?

#116

Post by nickez »

chubot wrote: post #24
ComputerGuru wrote: post #3

Lots of overlap in design goals with fish, except fish also places a premium on users interactively using the shell (which means friendlier in-repl experience but a balancing act when it comes to features). Fish’ auto completions are incredible, too. Best of luck to them. Another interesting shell to check out is elvish, lots of new ideas there (even if awkward to use). (Disclosure: I’m one of the core fish devs/main…

(author here) Hm I've tried fish, and it seems very nice for interactive use. However I don't see it being used AT ALL for the cloud/linux use case? Those are the cases where you tend to get 1000+ lines of shell scripts. For example, I mention Kubernetes/Docker/Chef, and I've never seen fish in that space. I also don't know of any Linux distro that uses fish as their foundation -- they all appear to use a POSIX shell…

What is your take on Ion? https://doc.redox-os.org/ion-manual

Re: Why Create a New Unix Shell?

#117

Post by qwerty456127 »

ComputerGuru wrote: post #3

Lots of overlap in design goals with fish, except fish also places a premium on users interactively using the shell (which means friendlier in-repl experience but a balancing act when it comes to features). Fish’ auto completions are incredible, too. Best of luck to them. Another interesting shell to check out is elvish, lots of new ideas there (even if awkward to use). (Disclosure: I’m one of the core fish devs/main…

Indeed Fish is bloody amazing! I've been using bash for my whole life and now as I've seen Fish I don't want to see any other shell (except some new one that might happen to be made even better) ever. It feels like a quantum leap of the same kind like the switch from ancient printer-oriented Unix shells (that didn't even let you edit the part of the command you've already entered) to bash.

As for the scripting language part, however, I have always been wondering why do people use headache languages like bash/sh when we have Python. Might anybody have a clue - I'd appreciate if you could share.

Re: Why Create a New Unix Shell?

#118

Post by [deleted] »

chubot wrote: post #58
oleks wrote: post #35

Why is Oil implemented in Python? IMO Python is a terrible language for writing programming languages.

I will address that in part 2 of the FAQ, but the short answer is: 1) I prototyped it in Python; the dependency on the Python interpreter will be removed [1] 2) Oil went through many implementation languages, and one incarnation was 2000-3000 lines of C++. But I realized I would NEVER finish that way. The goal is to be compatible with bash, which is a tall order. 3) Oil is heavily metaprogrammed. It's only 16K lines…

[deleted]

Re: Why Create a New Unix Shell?

#119

Post by ComputerGuru »

dflock wrote: post #92
Osiris wrote: post #73

Earlier quoted context omitted.

fish-shell is the first thing I install on any *nix box I work on, including macOS, VPS servers, desktop (Ubuntu), and even Windows Subsystem for Linux. The feature I use the most is automatic history search by typing part of a command and hitting UP to search the history. I also find the scripting language more straight-forward.

> The feature I use the most is automatic history search by typing part of a command and hitting UP to search the history. This is available in bash/sh by setting this in your ~/.inputrc file: "\e[A": history-search-backward "\e[B": history-search-forward "\e[C": forward-char "\e[D": backward-char

I used bash first, then zsh. You have to try fish, it shows a "ghost" of the first matching autocompletion on the same line, which changes dynamically as you type. It also has a cool memory effect for figuring out history completions based off the directory you are in.

Like csh on FreeBSD, alt+(up/down) can be used to search history for arguments instead of lines, so if you do something like

   touch some/long/directory/path/to/file
   ....
   rm so
fish will search all individual arguments (correctly handling quoted spaces, etc) for arguments starting with "so" and it'll suggest the path in question, even though the head here (`rm`) differs from the original (`touch` in this case).

Re: Why Create a New Unix Shell?

#120

Post by ufo »

qwerty456127 wrote: post #117
ComputerGuru wrote: post #3

Lots of overlap in design goals with fish, except fish also places a premium on users interactively using the shell (which means friendlier in-repl experience but a balancing act when it comes to features). Fish’ auto completions are incredible, too. Best of luck to them. Another interesting shell to check out is elvish, lots of new ideas there (even if awkward to use). (Disclosure: I’m one of the core fish devs/main…

Indeed Fish is bloody amazing! I've been using bash for my whole life and now as I've seen Fish I don't want to see any other shell (except some new one that might happen to be made even better) ever. It feels like a quantum leap of the same kind like the switch from ancient printer-oriented Unix shells (that didn't even let you edit the part of the command you've already entered) to bash. As for the scripting langua…

At its best, invoking commands and pipelines in shell is much more pleasant than doing the same in Python with subprocess and so on. The flipside is that at its worst, shell is a horrible language.
Post reply on HN