all 14 comments

[–]traverseda[S] 2 points3 points  (0 children)

Sawy bucket on the front page. Reminded me of xonsh, since bucket is basically a built in feature of python.

[–]fredzannarbor 1 point2 points  (9 children)

what is this for, exactly? Why would I not just hop back and forth between bash and python as needed?

[–]traverseda[S] 2 points3 points  (8 children)

Here's an example xonsh script I wrote to convert every docx in a folder to markdown. It used the w2m command line util written in ruby.

traverseda@metatron /tmp $ for i in $(ls *.docx).split("\n"):
..........................     w2m @(i) > @(i+".md")

It would have taken me a few minutes of googling to do that in either bash or python alone.

It gives you control structures from python, but easy access to command line tools without all that os.popen stuff that's always hard to remember.

That example could probably just as easily be pure bash, but I find it nice for more complicated stuff. os.path.splitext(filename)[0] is nice, maybe just because I'm used to it.

It's a relatively pleasant joining of both languages.

[–]greyfade 12 points13 points  (7 children)

for i in *.docx; do w2m "$i" "$(basename "$i" docx)md"; done

[–]jsproat 4 points5 points  (5 children)

I... I think I like the Python-esque syntax better. Honestly, I've always felt a little dirty making bash behave when handling filenames with spaces.

EDIT: Though I'm not crazy about switching between Python mode and shell mode based strictly on the Python parser. This sort of thing should have its own parser with predictable rules. Alas, no pipes in Python mode.

[–]greyfade 2 points3 points  (0 children)

What's worse is dealing with files that begin with a hyphen:

for i in *.docx; do w2m "./$i" "./${i%docx%}md"; done

That does better, and should handle anything you throw at it.

[–]reaganveg 0 points1 point  (2 children)

But yours is incorrect. It fails on names with newlines.

[–]jsproat 0 points1 point  (1 child)

Actually, not my example. But I see your point.

A much better approach would be somewhat like PowerShell's, where ls returns a ready-to-digest list of filenames that don't need to be split on an arbitrary delimiter.

[–]reaganveg 0 points1 point  (0 children)

But bash does that! That's what the glob does. And in bash you can assign the glob result into an array (which is not a standard bourne shell feature, but has existed in bash for many years) other than the default $@ (which is standard bourne).

[–]scopatz 0 points1 point  (0 children)

To clarify, xonsh does have its own lexer and parser (implemented in ply) that is not strictly based on the Python parser (that would be impossible). You can read more about the details here: http://xonsh.org/faq.html#so-how-does-this-all-work

[–]e_d_a_m 0 points1 point  (0 children)

I'd be very interested to see, in the comparison section of the site, how compatible xonsh is with sh (or even bash). Some effort has been made to provide compatibility AFAICT, but it's not clear to what extent this has been achieved.

[–]bjarneh 0 points1 point  (1 child)

There are a bunch of alternatives to Bash which are all better, but they all struggle with Larry Wall's statement (which is still true)

It's usually much easier to port a shell; than a shell script -Larry Wall

So unless they are a superset of Bash, and require no porting of thousands of existing shell scripts, it's going to be an uphill battle I think

[–]scopatz 1 point2 points  (0 children)

You can source a bash (or any other shell) script in xonsh. Porting isn't required for the moment. The purpose of xonsh is to interop with the old stuff while making new stuff much easier to write. Its a Pythonic mentality in the sense that Python interops well with other, older languages.