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

Four features that justify a new Unix shell

oilshell.org

Post reply on HN
Print view View original

151–160 of 185 posts

Re: Four features that justify a new Unix shell

#151

Post by m45t3r »

mikepurvis wrote: post #102
jonahx wrote: post #67

Earlier quoted context omitted.

The author addresses this argument: > 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. From: http://www.oilshell.org/blog/2018/01/28.html#i-dont-unde…

Even something that should be as simple as piping output from one process to another in Python is a nightmare, and fraught with opportunities to shoot yourself in the foot with buffering deadlocks and other nonsense. The consequence of this is that many of my projects which require these overlapping domains (think stuff like build automation) ends up being the two interleaved— either an outer shell script that calls…

> Even something that should be as simple as piping output from one process to another in Python is a nightmare, and fraught with opportunities to shoot yourself in the foot with buffering deadlocks and other nonsense.

This is true, but when I am writing a script in Python I generally don't need to pipe as often as I do in bash. Python offer many replacements for things that in Bash you need to call another process.

That is, of course, if performance isn't necessary. When it is bash is still unbeatable because of the pipes.

Re: Four features that justify a new Unix shell

#152

Post by toastal »

breatheoften wrote: post #3

Are there any transpile to bash languages? I like the idea of a language that allows for a better experience in writing shell scripts -- and produces shell scripts with fewer bugs on the output side. But i wonder if a transpile approach wouldn't be better in the long run

Tangentially you can use Dhall to get many types for Bash. You can have your options/configuration typed, then have Bash run a loop over it or whatever you need ho do.

Re: Four features that justify a new Unix shell

#153

Post by d0mine »

mikepurvis wrote: post #102
jonahx wrote: post #67

Earlier quoted context omitted.

The author addresses this argument: > 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. From: http://www.oilshell.org/blog/2018/01/28.html#i-dont-unde…

Even something that should be as simple as piping output from one process to another in Python is a nightmare, and fraught with opportunities to shoot yourself in the foot with buffering deadlocks and other nonsense. The consequence of this is that many of my projects which require these overlapping domains (think stuff like build automation) ends up being the two interleaved— either an outer shell script that calls…

Here's how to pipe two commands in Python:

    import subprocess

    subprocess.check_call("command1 | command2", shell=True)
Depending on your use case there are other options e.g., fabric http://fabfile.org plumbum

Use shell for what is really good for: concise DSL for running commands (one-liners). Leave complex logic (branches, explicit loops) for sane general purpose languages such as Python.

Re: Four features that justify a new Unix shell

#154

Post by Kuinox »

sedatk wrote: post #107
Kuinox wrote: post #103

Earlier quoted context omitted.

Powershell is a bit better, but got it's own disadvantage: Despite the consistent naming, I can't remember correctly the modules names. Running Remove-NetFireWallRule without arguments delete all the firewalls rules despite a flag "-All" not being set. The learning curve is too hard, or it's too complex to learn on the job: It takes me at least half an hour to write semi-complex commands despite the number of hours I…

> And it still suck as a scripting language. Why do you think that? I find PowerShell quite neat and more consistent than what bash and alike has to offer.

It does "resume on error" by default.

It got script languages issues: The last line of your huge script may be syntaxically invalid. Here you start thinking "why I didn't wrote it in my favorite statically compiled language"

Yes, it's still more consistent than what bash and alike has to offer, but it's still behind if you compare it to any language that you can write to a file.

The only advantage it got against them, it's the huge API on windows.

Sadly I wanted to use Powershell functions from C#, tought it would be easy because Powershell use .NET Core, but it's far from easy.

Re: Four features that justify a new Unix shell

#155

Post by sergeykish »

esaym wrote: post #92
FreshFries wrote: post #71

Earlier quoted context omitted.

There is nothing in the (IT) world I fear more then... Perl projects. The shear madness it will leash upon you when the dependencies fail is maddening. Never will I voluntarily touch anything written in Perl ever again in my live. I've seen the power of Perl, the beauty and elegance of it, but everything was ruined by the absolute shit show when it comes to its packet managers. /rant.

I think the OP is mostly talking about "perl one liners" on the shell like this: https://catonmat.net/ftp/perl1line.txt It is not that hard either (unless perl is completely foreign to you). Ironically just today I wrote a python script (using concurrent.futures) to batch re-encode 10gb of mp3 podcasts into 3gb of opus files to save space. Before I deleted the old mp3's, I did a quick file count of mp3 and opus files…

It would be simpler (and match "everything after the last '/'") with

    perl -nle 'if( $_ =~ /([^\/]+)$/) { print "$1"}'
I don't quite get how can stream of '* \.ogg' proceed through /[\w-]+.\w\w\w$/ filter. Notice space.

And it allows ",ogg" (dot not escaped so it is not extension), thankfully find provides /\.ogg$/

Re: Four features that justify a new Unix shell

#156

Post by [deleted] »

high_priest wrote: post #106
esaym wrote: post #92

Earlier quoted context omitted.

I think the OP is mostly talking about "perl one liners" on the shell like this: https://catonmat.net/ftp/perl1line.txt It is not that hard either (unless perl is completely foreign to you). Ironically just today I wrote a python script (using concurrent.futures) to batch re-encode 10gb of mp3 podcasts into 3gb of opus files to save space. Before I deleted the old mp3's, I did a quick file count of mp3 and opus files…

Why am I not surprised that the PERL part could be solved with bash in the same space. Why are you so eager to use lang on top of lang, in such simple cases?

[deleted]

Re: Four features that justify a new Unix shell

#157

Post by ubercow13 »

esaym wrote: post #110
high_priest wrote: post #106

Earlier quoted context omitted.

Why am I not surprised that the PERL part could be solved with bash in the same space. Why are you so eager to use lang on top of lang, in such simple cases?

Feel free to demonstrate. Take a long path with nasty characters and give me the ending file name. I want "track1.mp3" returned from: /podcast/with/nasty'--c h a r$/and/stuff/track1.mp3

In zsh it would be

    echo “${uglypath:t}”

Re: Four features that justify a new Unix shell

#158

Post by aljarry »

barumi wrote: post #147
dimator wrote: post #139

Earlier quoted context omitted.

This is ridiculous. Python won scripting because it offers a sane way to do sequential, shell-ish things, without having to wade through "man bash" or searching stack overflow for the umpteenth time about the syntax to do something that should be trivial but is anything but. Saying that younger devs only know python is like a FORTRAN engineer in the 90s saying young devs only know java. No one needs to apologize for…

> This is ridiculous. Python won scripting because it offers a sane way to do sequential, shell-ish things, without having to wade through "man bash" or searching stack overflow for the umpteenth time about the syntax to do something that should be trivial but is anything but. You've inadvertently supported exactly my point. You just advocate for the lazy way out. You know Python, so that's what you use and nothing m…

So you say we should choose the hard way, because the easy way is lazy?

Also, your point can be turned around - you could use python which produces readable and maintanable code, but instead you choose the easy, lazy way of using bash, which you already know really well.

Re: Four features that justify a new Unix shell

#159

Post by sergeykish »

zimpenfish wrote: post #117
esaym wrote: post #110

Earlier quoted context omitted.

Feel free to demonstrate. Take a long path with nasty characters and give me the ending file name. I want "track1.mp3" returned from: /podcast/with/nasty'--c h a r$/and/stuff/track1.mp3

If you have that in a variable, which you presumably would if you're reading them one at a time, you can use "remove longest matching prefix" substitution. $ i="/podcast/with/nasty'--c h a r$/and/stuff/track1.mp3" $ echo "${i##*/}" track1.mp3 [Edit: 'thezilch beat me too it by a couple of minutes]

This part is really cryptic, I would prefer

    $ function remove_longest_matching_prefix () { echo "${1##$2}"; }
    $ remove_longest_matching_prefix "$i" '*/'
    track1.mp3
awk -F/ accepts stream as in perl example

Re: Four features that justify a new Unix shell

#160

Post by IggleSniggle »

qznc wrote: post #143
IggleSniggle wrote: post #98

Doesn't TCL (and tclsh) handle these top four features quite elegantly? I understand why people shudder at TCL, but they are mixing up the elegance of the language with the dysfunction of the situation it was pulled in to address. Yes, when you start gluing random stuff together it gets ugly. This is true in real-life too. That's the situation. TCL, from the "commands and strings" handles this quite elegantly with a…

TCL has a very simple model of a shell "REPL": interpret string as expression and evaluate. In contrast, a Unix shell has job control, stderr, pipes, etc.

I’m struggling to understand how you don’t get these features with tcl / tclsh.

You get job control, familiar access to your file system and the usual conventions around command execution of binaries in your PATH (like ps, kill, etc), you have stderr, you have pipes...

...but you also have a language that is immediately polyglot because of the way it uses strings. Each string reference is analogous to a file-descriptor; a function pointer that can be redirected and executed in whatever context, while also feeling like native context scopes in any languages you might want to use to interpret/compile them due to their use of the {} delimiter.

Post reply on HN