Live data from Hacker News

Why Create a New Unix Shell?

oilshell.org

151–160 of 298 posts

Re: Why Create a New Unix Shell?

#151
post #109
post #68

In your FAQ you decry Perl as having no ability to redirect around other programs. Yet you don't explain how any of the following fail to meet those needs.: * http://perldoc.perl.org/functions/open.html * http://perldoc.perl.org/IPC/Open2.html * http://perldoc.perl.org/IPC/Open3.html * http://search.cpan.org/~odc/IPC-Open2-Simple-0.01/lib/IPC/Op... * http://search.cpan.org/~exodist/Child-0.013/lib/Child.pm * http://s…

Can you show me some code? How do you write this in Perl? f() { echo -- ls / echo -- } f > out.txt f | wc -l

I'm not sure why you'd want a count that includes your delimiter lines nor why you'd want to run the binaries twice for that matter. Real programming languages, including Bash, have variables.

There are a number of ways to do these same things. Some of them mirror your code more closely than others. Here's my first shot using a core module, since someone already did one with no modules that works much like your code.

    use IPC::Run3;
    my @lines;

    sub f {
        my @command = qw( ls / );
        run3 \@command, \undef, \@lines;
    }

    f();
    open my $out, '>','out.txt' or warn "can't write to out.txt : $!\n";
    printf $out "--\n%s--\n", (join '', @lines);
    print scalar @lines . "\n";


Now I'd make that a bit cleaner and more reusable of course. I'd probably take the commands to run from the command line or a configuration file. I'd probably return an array or use a reference to one rather than making a file-level lexical array and just using that from a subroutine.

Re: Why Create a New Unix Shell?

#152

Earlier quoted context omitted.

yeah I can actually imagine that. like using an IDE based on the language it was written in to extend and tweak it more easily, or a window manager etc.. actually now you mentioned it, barring possible performance issues I'd also like a Python distro

> an IDE based on the language it was written in I recommend Emacs. Maybe not as a daily driver (it's a matter of preference), but for the experience. I recommend at least a month with it, make sure to write some original Lisp code for your customisations. (You WILL end up customizing it, the defaults are crap.) > or a window manager I recommend Awesome. The core is in C, but that's basically the low-level stuff, the…

Wait, what? You recommend Emacs but not StumpWM?

I've used -- for longer periods of time, of course -- Awesome, Xmonad, i3, and dwm; while some of them are better at some things than StumpWM, StumpWM is the only one that provides an Emacs, live-hackable experience. So these days, I strongly prefer that.

Re: Why Create a New Unix Shell?

#153
post #144

Earlier quoted context omitted.

Back when I started programming, I wrote 1000+ lines of shell scripts. Now, I quite seriously believe that a 1000 line shell script only exists out of error. I still occasionally end up doing 2-300 line dense shell scripts, but not without feeling very dirty along the way. Either split into small, simple shell scripts (which is fine), or a different language. In the cross platform build pipeline at work, I keep a str…

My personal threshold for upgrading from shell to Python is about "I need an if statement".

Yeah I've seen that Python code. Every other line is a call to os.system('...').

Re: Why Create a New Unix Shell?

#154
post #10

Finally a modern shell that understands the importance of COMPATIBILITY! This gives it a realistic chance of getting real adoption. Shells like zsh and fish will never get mainstream adoption because they are not compatible with bash.

As someone who now seems to send patches for gratuitous and unnecessary Bashisms in purported #!/bin/sh scripts in Free Software on a regular basis, you had me in agreement about compatibility right up to the Bash part.

Re: Why Create a New Unix Shell?

#155

Earlier quoted context omitted.

> I quite seriously believe that a 1000 line shell script only exists out of error. Perhaps the best use case for Oil is to provide a debugging environment where you can figure out what your legacy shell scripts are doing, and rewrite them in another language. > Unlearning bash-isms is not a liberty I can afford, as I need to be proficient when I SSH into a machine I do not own or control. This is a slippery slope. I…

> Forcing yourself to always use the lowest common denominator of software is not a fun path. Second this. Been there, and back, and there again, and recently back again. Customize the hell out of your shell, make it your place, make it nice. You're spending your day there, every day. Treat it like you'd treat your work desk. If it's a stranger's machine, well, OK, suffer through the 10 minutes of troubleshooting, an…

While I appreciate your perspective, I think it’s more from the “occasional SSH to a foreign server” mindset. Scaling “the way I work in a shell” to huge fleets is a nonstarter, and as a working SRE, has been the biggest thing holding me back from zsh, fish, and other alternatives.

OTOH, I’m also against, for example, installing zsh fleetwide in production fleets to accommodate choosy folks. So I’m on both ends of the problem, and know it.

Re: Why Create a New Unix Shell?

#156
post #132

Sounds pretty cool and everybody who had to learn bash scripting at some point understands why we need a sane language (my favorite are misplaced spaces in if statements...; Disclaimer: I do and love bash scripting but while the language has cool concepts, some things are just broken by design). Nevertheless, there is one piece in this puzzle I am missing. There does not seem to be a process which manages the 'core s…

What you are describing has been around since the late 1980s, IEEE POSIX: https://en.wikipedia.org/wiki/POSIX

Re: Why Create a New Unix Shell?

#157

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…

Tell me if this is just me being a novice but the main dealbreaker for me with Fish was the fact that I had to re setup every thing like PATHS and stuff (tbh i'm not really sure what. There is a long list of weird customizations i've made to support various projects/libraries/etc, copied off stack overflow, that I don't remember) I would try to run commands that work in bash that wouldn't work in Fish. I would get so confused by it all that I just took fish off, as much as i liked it.

Re: Why Create a New Unix Shell?

#158

Earlier quoted context omitted.

> Forcing yourself to always use the lowest common denominator of software is not a fun path. Second this. Been there, and back, and there again, and recently back again. Customize the hell out of your shell, make it your place, make it nice. You're spending your day there, every day. Treat it like you'd treat your work desk. If it's a stranger's machine, well, OK, suffer through the 10 minutes of troubleshooting, an…

While I appreciate your perspective, I think it’s more from the “occasional SSH to a foreign server” mindset. Scaling “the way I work in a shell” to huge fleets is a nonstarter, and as a working SRE, has been the biggest thing holding me back from zsh, fish, and other alternatives. OTOH, I’m also against, for example, installing zsh fleetwide in production fleets to accommodate choosy folks. So I’m on both ends of th…

It's actually not that difficult to maintain context if you use completely different shells (with different-looking prompts) on your own machine vs the fleet. It's like code-switching when you talk to your friends at the bar vs co-workers.

Re: Why Create a New Unix Shell?

#159
post #9

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…

Shameless self promotion but I'm writing my own shell, murex, as well[1] The goals of mine are akin to Fish in terms of REPL use but with a greater emphasis on scripting. Like Fish, murex also does man page parsing (in fact I wrote mine before realising Fish did the same), but unlike fish autocompletions can be defined by a flat JSON file (much like Terraform) as well as dynamically with code. Currently I'm working o…

I just have to say, that's a beautiful name for a shell.

Re: Why Create a New Unix Shell?

#160

> However, Python and Ruby aren't good shell replacements in general. Shell is a domain-specific language for dealing with concurrent processes and the file system. But Python and Ruby have too much abstraction over these concepts, sometimes in the name of portability (e.g. to Windows). They hide what's really going on. Excellently put. POSIX shell languages have fantastic capabilities you just can't get in most othe…

Shell is my favorite domain-specific language. But many (including myself) would argue that domain-specific languages are generally better embedded. Many projects aiming to mixing shell with general purpose languages find a nice embedded DSL for subprocess/pipeline management. Some others find a convenient way to run shell commands or pipelines by mixing grammars and trying to disambiguate them. [Shameless self-promo…

FWIW I have your project on my wiki page :)

https://github.com/oilshell/oil/wiki/ExternalResources

I guess what you mean by embedded is that it should be an embedded DSL in a full-fledged programming language? I don't quite agree, since there are at least 20 projects like that on the wiki page, none of which is popular.

Probably the most popular one is eshell, in Emacs Lisp?

But if there's something I don't know about I'd be interested in hearing it. This idea goes back at least 20 years, e.g. to scsh. And it hasn't taken off.

But certainly I don't begrudge anyone if their favorite environment is Racket and they want to stay in Racket. That's a perfectly reasonable thing. It's just not what I would expect anyone besides racket users to use.

One reason I'm interested in shell because it's the lowest common denominator between different groups of programmers. C/C++ programmers, use it heavily, Python, Ruby, JS programmers, Go, etc. Everybody uses it.

Post reply on HN