Live data from Hacker News

Marcel the Shell

marceltheshell.org

181–190 of 209 posts

Re: Marcel the Shell

#181

Earlier quoted context omitted.

I believe you are missing the point. It's not about sed and awk. It's the string oriented approach to data requiring heavy usage of these tools for parsing the unstructured text. The suggested alternative is the object oriented approach, just like PowerShell and the OP's project are based on.

Well there are two points. 1) Piping strings is dumb. 2) Multiple incompatible sublanguages has a long learning curve. How many people can just write complex awk/find scripts without checking the manual? Using marcel, and knowing python, I can do those complex things without RTFM.

I use bash, find, sed and awk every day, usually ten to twenty times per day. I've also built a lot of scripts for my company's workflow with those tools.

I've never read the manual for any of these. They all work on the same concept of lines and words, which is intuitive and easy to interact with on the terminal.

Piping strings and making lines and words the units of work are the great ideas of UNIX.

I sometimes use python instead, but while it yields better programs, it takes a lot more time and just isn't suited to being written in the shell, especially with the syntax being whitespace-sensitive.

Re: Marcel the Shell

#182

Earlier quoted context omitted.

sed and awk are simple tools; choosing an entirely different non-standard tool just because you can't learn them seems a bit overkill.

I believe you are missing the point. It's not about sed and awk. It's the string oriented approach to data requiring heavy usage of these tools for parsing the unstructured text. The suggested alternative is the object oriented approach, just like PowerShell and the OP's project are based on.

but it is structured, you have multiple lines and each line has multiple words.

Re: Marcel the Shell

#183

Earlier quoted context omitted.

Text does work, but text data exchange formats come in and out of vogue just like binary. And when any structure is needed, we typically get some ad-hoc text format that doesn't interoperate. JSON has made things better here, but it's a bit of a verbose eyesore for humans. I think the lack a structured (text based) format is a definite shortcoming in UNIX. Whitespace delimited lists of strings do get you surprisingly…

While I think that ASCII including a specific record delimiter character (0x1E) that isn’t used is a missed opportunity, I actually think the lack of a set interchange format is a benefit. No format will work for everyone and if there was one set format, we’d still have people complaining about how it doesn’t work for their usecase. We'd also have had to (finally) answer the question of how to send the schema with th…

I'm not saying that processes wouldn't be free to spit out raw ASCII or whatever if they so wanted, but there should be some sort of POSIX-type standard that would spec typical output formats (e.g. standard --yaml flag). I see no urgent need for formal sending of schemas.

It's a disgrace that most standard tools don't have even an option for any machine readable output. Or when they do, they are ad-hoc and there are ad-hoc parser tools/flags for those. I.e. you need a lot of (badly implemented) specialized tools.

You can grep, sed and awk YAML all you want. It's just ASCII (or UTF-8) text.

Re: Marcel the Shell

#184
post #86

First of all - Linuxes and alike desperately need something like this shell becoming standard. And second - I always wonder how all these great minds who where throwing rubbish at Microsoft ever since... somehow forgot to mention that same company created important product called PowerShell like 20 years ago. And you know PowerShell is so good already you can easily drop it in any OS/X, Linux and it actually works. N…

It is funny that sed and awk are often uttered together as one incantation, while in fact they are very different tools.

Sed is, I dare to say, one of these quick-hack tools Unix is full of; awk in turn os a great mini-language with the defaults and builtins allowing for very concise programs.

What they share in common is processing lines and using regexes, and here's where similarities end.

While there is this sentiment to attribute a notion of "oldness" to awk, it is very powerful tool and is being implemented every decade (hello, GoAwk!). The rhetorical question, if it's so ancient and legacy, whether it's being reinvented every now and then?

This is a little detour from the original point, that was: processing structured data. Going back to this, I think there is important distinction: are we ok with the tools processing raw input/output and interpreting structure internally, or are we in a desperate need to preserve the structure in the piping mechanism, like Marcel does? The latter ofc gives more power; but the former retains the compatibility with all the tools that don't know the structure.

Re: Marcel the Shell

#185
post #90

Earlier quoted context omitted.

I need to write about it ;). We won that case just before the last election and unfortunately other things took priority at the time. But it'll happen. Just first need to write about my IL supreme Court loss...

I would love to read about stuff like this. I hope you'll post here when you eventually write it up.

This might quench your thirst in the meantime!

https://mchap.io/that-time-the-city-of-seattle-accidentally-...

Re: Marcel the Shell

#186
post #170

Earlier quoted context omitted.

When the alternative is to fire up some mess of an IDE with some nightmearish COM/.NET/ProtoBuf/whathaveyou overengineering marvels, I take grep and sed every time. Simple text-based structured data format (something like YAML) with possibility to embed binary would be the way to go IMHO. And of course one should be able to show graphics in the terminal. But we're not gonna get it. Open source tol is being rapidly en…

I don't know why you seem to think we can only have "super-lightweight 2kb C binary" or "giant over engineered Java-IDE" - there's lots of space in between. I don't think anybody would want to give up snappy terminals, but at the same time, why does this have to imply loosing out on half a century of user experience research??

The original proposal in the thread was PowerShell+IDE. That's overengineering on top of overengineering on top of overengineering.

Re: Marcel the Shell

#187

Earlier quoted context omitted.

When the alternative is to fire up some mess of an IDE with some nightmearish COM/.NET/ProtoBuf/whathaveyou overengineering marvels, I take grep and sed every time. Simple text-based structured data format (something like YAML) with possibility to embed binary would be the way to go IMHO. And of course one should be able to show graphics in the terminal. But we're not gonna get it. Open source tol is being rapidly en…

Well, that looks like a straw man fallacy. Assuming the only alternative is a full-blown enterprise IDE for a Unix shell is at least a strawman.

IDE on top of PowerShell was the proposal in this thread.

Re: Marcel the Shell

#188
post #18
post #12

Earlier quoted context omitted.

Honestly any interactive shell + unix tools + any scripting language you feel comfortable with should cover the majority of things you may want to do on the command line.

For a lot of 8-bit computers, BASIC was the default operating system shell.

Not exactly BASIC per se, there was some CP/M like additions. However, you're right 'cause some of those commands are BASIC extension (e.g. RUN can be used from your programme, LIST maybe, but CATalog/DIRectory or LOAD often not.) Old good time.

Re: Marcel the Shell

#189
post #184
post #86

First of all - Linuxes and alike desperately need something like this shell becoming standard. And second - I always wonder how all these great minds who where throwing rubbish at Microsoft ever since... somehow forgot to mention that same company created important product called PowerShell like 20 years ago. And you know PowerShell is so good already you can easily drop it in any OS/X, Linux and it actually works. N…

It is funny that sed and awk are often uttered together as one incantation, while in fact they are very different tools. Sed is, I dare to say, one of these quick-hack tools Unix is full of; awk in turn os a great mini-language with the defaults and builtins allowing for very concise programs. What they share in common is processing lines and using regexes, and here's where similarities end. While there is this senti…

This is a false choice. You can start with minimal structure, add it for intermediate processing and then go back to text, if you’d like. Marcel can run native commands, piping their output into other Marcel commands, as a steam of strings.

Re: Marcel the Shell

#190
post #164

Earlier quoted context omitted.

I don't see anything connecting the marcel site and the oilshell.org site, am I missing something (like, say, "this is a different osh") or did you just not get around to writing that up yet? (to be clear, this isn't a complaint, I'm just confused and asking for help becoming unconfused, I'm aware how lists of things to get around to writing up tend to be a grow-only datastructure for us all ;)

Sorry, osh as in object shell: https://github.com/geophile/osh .

Aha! Thank you!
Post reply on HN