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

Marcel the Shell

marceltheshell.org

Post reply on HN
Print view View original

191–200 of 209 posts

Re: Marcel the Shell

#191

Post by geophile »

mgaunard wrote: post #181
geophile wrote: post #177

Earlier quoted context omitted.

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…

Yes. They work with lines and words, but the sublanguages are hideous.

Re: Marcel the Shell

#192

Post by feldrim »

mgaunard wrote: post #182
feldrim wrote: post #172

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.

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

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

This is sarcasm, right?

Re: Marcel the Shell

#193

Post by hnlmorg »

JeremyNT wrote: post #157
skrebbel wrote: post #94

Earlier quoted context omitted.

In defense of the Microsoft-haters, powershell is a fantastic idea with terrible ergonomics. When they first released it I was very excited but, well, it’s just awful to use. Terrible Get-Finger-Twister -Recurse -Awfully commands, quirky aliases (you can type “curl” but it takes none of curl’s parameters because it’s an alias for Get-WebRequest-Annoyingly or whatever they called it), simple scripting things such as “…

Yeah, it's in this weird space where the underlying technical direction feels correct but it's just too cumbersome in actual practice. The awful text manipulation in posix shells feels wrong on a lot of levels, but when you're just trying to accomplish something quickly the "just manipulate strings, always" api is faster to actually work with interactively. Powershell ends up in this weird space where it's clearly be…

This is why I created my own shell. I wanted something better than Bash but less cumbersome than Powershell (plus Powershell wasn't even available for Linux back when I started).

There is a massive gulf between Bash and Powershell -- they're opposite ends of the spectrum -- and it's entirely possible to have something that cherry picks the convenience of Bash with the power of Powershell. Albeit compromises would still have to be made.

There's quite a few alt shells these days now though. So other developers have clearly had the same thought as myself.

Re: Marcel the Shell

#194

Post by throwawaaarrgh »

benatkin wrote: post #92
throwawaaarrgh wrote: post #79

Earlier quoted context omitted.

[flagged]

It is a useful correction. This project predates the release of the movie: https://github.com/geophile/marcel/commit/bb6adacbb6b3a683ce...

And the online video series (that is described in the movie) predates the name of this project by a decade.

Who gives a shit? Why do some people feel the need to correct every little thing?

Re: Marcel the Shell

#195

Post by mbreese »

jampekka wrote: post #183
mbreese wrote: post #175

Earlier quoted context omitted.

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…

I’m trying to think about what kind of tools would benefit from such an option…

An obvious first tool would be “ls” to produce an easier to parse output. From there, maybe a “grep” to search fields and “sort” to sort by fields.

I guess I can think of many consumers or YAML-like data, but what would some of the producers be?

Re: Marcel the Shell

#196

Post by geophile »

jampekka wrote: post #137
pjmlp wrote: post #129

Earlier quoted context omitted.

Welcome to the world of Lisp Machines, Xerox PARC and ETHZ. Unfortunely taken away due to UNIX's free beer offerings.

I almost daily daydream of the alternate timeline where MBAs and greed didn't destroy Lisp Machines. And lament that we ended up with this horrible pile of hacks that makes everything needlessly painful.

Is that what happened? MBAs and greed destroy a lot, but I’m not sure about Lisp machines. Beautiful hardware and software, but unbelievably expensive, and custom hardware was bound to lose out on performance.

Re: Marcel the Shell

#197

Post by jampekka »

mbreese wrote: post #195
jampekka wrote: post #183

Earlier quoted context omitted.

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…

I’m trying to think about what kind of tools would benefit from such an option… An obvious first tool would be “ls” to produce an easier to parse output. From there, maybe a “grep” to search fields and “sort” to sort by fields. I guess I can think of many consumers or YAML-like data, but what would some of the producers be?

ls is a good example. Getting the -l output would be very useful for many applications. And would simplify ls itself (e.g. sorting could be done in a separate generig util, which would work with other tools as well). Would also take care of the whitespace horrors.

Many tools don't have "stable CLI interface", which makes them difficult to automate. Apt and git come to mind immediately (although git generally allows specifying formats). Some tools (e.g. ffprobe) support JSON output, which provides very easy "bindings" for it (the actual libav APIs are quite painful).

Re: Marcel the Shell

#198

Post by jampekka »

geophile wrote: post #196
jampekka wrote: post #137

Earlier quoted context omitted.

I almost daily daydream of the alternate timeline where MBAs and greed didn't destroy Lisp Machines. And lament that we ended up with this horrible pile of hacks that makes everything needlessly painful.

Is that what happened? MBAs and greed destroy a lot, but I’m not sure about Lisp machines. Beautiful hardware and software, but unbelievably expensive, and custom hardware was bound to lose out on performance.

Symbolics/Noftsker is often attributed as the reason for the Lisp "split" and turning Lisp machines proprietary (and needlessly expensive).

The arrival of microcomputers, and horrors like Microsoft, were of course a major reason too.

https://www.gnu.org/gnu/road-to-gnu.en.html#betrayed

https://www.gnu.org/gnu/road-to-gnu.en.html#betrayed

Re: Marcel the Shell

#199

Post by happymellon »

geophile wrote: post #166
happymellon wrote: post #80

Earlier quoted context omitted.

Yes, in this scenario the LGPL was created so that I could create a library, and if anyone modified my library they had to share the improvements however using my library does not then apply the GPL to your code.

So switching from GPL to LGPL would allow the G*P to use marcel.api?

https://en.m.wikipedia.org/wiki/GNU_Lesser_General_Public_Li...

> The license allows developers and companies to use and integrate a software component released under the LGPL into their own (even proprietary) software without being required by the terms of a strong copyleft license to release the source code of their own components. However, any developer who modifies an LGPL-covered component is required to make their modified version available under the same LGPL license.

Yes. If they modify marcel.api they are bound by the LGPL to release their modifications, however they are not bound to release their application if they use marcel.api

There is GPL, LGPL and AGPL (probably others).

GPL code is viral, think of Linux and if you incorporate Linux code in your code them you have to GPL it, which means if you distribute it you have to give a copy of the source to your customers.

AGPL is newer and extended this, because Amazon et al, took GPL software and offered it as a service, so didn't "distribute", could make their changes and offer it as a SAAS and not offer their code changes. AGPL covers this scenario and means that you have to offer the source if you provide network access.

LGPL is almost as old as GPL, and allows people to write libraries as open source, which Microsoft could use in Windows without GPL'ing Windows but would require improvements to the library made by Microsoft to be distributed.

But as always, read the label to make sure there isn't a side effect that we missed in this chat.

Re: Marcel the Shell

#200

Post by mbakke »

geophile wrote: post #166
happymellon wrote: post #80

Earlier quoted context omitted.

Yes, in this scenario the LGPL was created so that I could create a library, and if anyone modified my library they had to share the improvements however using my library does not then apply the GPL to your code.

So switching from GPL to LGPL would allow the G*P to use marcel.api?

The sister comment appears to be somewhat confused. The "virality" of GPL is that if you "link" a GPL program then your license must be compatible and the combination as a whole becomes GPL. Importing a library may count as a derived work/linking.

The LGPL was created to avoid this limitation and is a natural choice for programming languages and interpreters.

As an example, GNU Guile, an interpreter for the Scheme language, is LGPL licensed. Writing any nontrivial Scheme script requires importing code from Guile. If it was GPL then all scripts had to be GPL compatible; but since it's LGPL, programs using Guile modules can have any license (even proprietary).

Post reply on HN