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

181–185 of 185 posts

Re: Four features that justify a new Unix shell

#181

Post by sergeykish »

esaym wrote: post #171
sergeykish wrote: post #155

Earlier quoted context omitted.

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$/

Space was because HN uses it as italics and I don't know the escape. And yes there are cleaner ways, but the point was a real world example of having something not work out in pure shell but yet quickly barfing out something working with perl. And yes, looks like I didn't escape the dot, funny!

Got it. Sure, I like one liners and I like piping. Ruby is strongly influenced by Perl:

    $ find . -iname '*.ogg' | ruby -nle 'puts $1 if $_ =~ /\/([\w-]+\.\w\w\w)$/'
I think the reason people badmouth Perl is because it is safe. People claim PHP improved but all I can see is language without design. JavaScript has lots of bad parts and we should not talk about them. I like AWK matchers though not its functions. I am not familiar with Perl but it is designed.

Re: Four features that justify a new Unix shell

#182

Post by mikepurvis »

m45t3r wrote: post #151
mikepurvis wrote: post #102

Earlier quoted context omitted.

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.…

> Python offer many replacements for things that in Bash you need to call another process.

True, you're never going to pipe something to grep in Python when you can just capture the output and use the inbuilt regex capability.

That said, it can be surprising how much worse performance-wise Python can be than shelling out to external utilities. Consider the simple case of downloading and extracting a tarball. I found that check_call("curl path/to/thing.tar | tar -x", shell=True) was significantly faster than anything I could figure out how to do with requests streaming, httpx (async), and the inbuilt tarfile module.

Re: Four features that justify a new Unix shell

#183

Post by lizmat »

chubot wrote: post #95
R0b0t1 wrote: post #66

Earlier quoted context omitted.

There is a better option and its name is Perl. Perl mixes the ins of shell scripts like easy argument and output passing with complex and easy to use control structures. You could use Python, but having been forced to use Perl extensively Perl is the superior choice for a complex shellscript-like workload. There's less boilerplate in Perl. There's a couple Python projects that come close like Fabric, but Perl was lit…

I think Perl needs a real pipeline syntax, among other things: http://www.oilshell.org/blog/2018/01/28.html#are-you-reinven... That said, Oil is somewhat influenced by Perl: https://www.oilshell.org/release/0.8.3/doc/language-influenc... Also note this part of the original blog post, Python/JS/Ruby vs Perl/PHP: http://www.oilshell.org/blog/2020/10/osh-features.html#oil-l... I recently bought a copy of the Camel book…

> In contrast, Raku and Oil are statically parsed.

I don't know about Oil, and if I understand your use of "statically parsed" correctly, Raku is not statically parsed. A "use" statement can affect how Raku parses source code from there on, see e.g. the OO::Monitors module that adds a "monitor" keyword.

But even simpler, adding an operator changes the grammar. For instance, adding a postfix ! operator for faculty, can be as simple as:

    sub postfix:(\value) { [*] 1 .. value }
    say 5!   # 120

Re: Four features that justify a new Unix shell

#184

Post by chubot »

lizmat wrote: post #183
chubot wrote: post #95

Earlier quoted context omitted.

I think Perl needs a real pipeline syntax, among other things: http://www.oilshell.org/blog/2018/01/28.html#are-you-reinven... That said, Oil is somewhat influenced by Perl: https://www.oilshell.org/release/0.8.3/doc/language-influenc... Also note this part of the original blog post, Python/JS/Ruby vs Perl/PHP: http://www.oilshell.org/blog/2020/10/osh-features.html#oil-l... I recently bought a copy of the Camel book…

> In contrast, Raku and Oil are statically parsed. I don't know about Oil, and if I understand your use of "statically parsed" correctly, Raku is not statically parsed. A "use" statement can affect how Raku parses source code from there on, see e.g. the OO::Monitors module that adds a "monitor" keyword. But even simpler, adding an operator changes the grammar. For instance, adding a postfix ! operator for faculty, ca…

OK interesting, I guess the question is if "use" requires running (not just parsing) arbitrary code? I guess if it's like Python's "import", it does.

Changing the grammar could still be considered static parsing, as long as the change doesn't depend on the values of variables at runtime, e.g. your argv array or something.

I recall Larry Wall saying that Perl 5 was at times confused about the language it was parsing, and the goal was to fix that in Perl 6. I don't have a lot of experience with it, but yeah that claim could be wrong, or at least un-nuanced.

Re: Four features that justify a new Unix shell

#185

Post by lizmat »

chubot wrote: post #184
lizmat wrote: post #183

Earlier quoted context omitted.

> In contrast, Raku and Oil are statically parsed. I don't know about Oil, and if I understand your use of "statically parsed" correctly, Raku is not statically parsed. A "use" statement can affect how Raku parses source code from there on, see e.g. the OO::Monitors module that adds a "monitor" keyword. But even simpler, adding an operator changes the grammar. For instance, adding a postfix ! operator for faculty, ca…

OK interesting, I guess the question is if "use" requires running (not just parsing) arbitrary code? I guess if it's like Python's "import", it does. Changing the grammar could still be considered static parsing, as long as the change doesn't depend on the values of variables at runtime, e.g. your argv array or something. I recall Larry Wall saying that Perl 5 was at times confused about the language it was parsing,…

The process of exporting symbols is done in an EXPORT subroutine that can be provided by the module developer. This subroutne is supposed to return a Map of symbol names and what they refer to. This Map can be constructed depending on external factors such as an argv array or an environment variable, although I have yet to see this in the wild.

So I guess one could say that Raku parsing is usually static, but it does not need to be.

Post reply on HN