Marcel the Shell
marceltheshell.org
marceltheshell.org
But for PowerShell to become Python on Perl steroids on top of all the .NET and COM+ there is, well, of course it took years, and top engineers to work on it, but also was needed an unified interface (API) to the underlying OS magic. Which is not there in Linux the same sense .NET became "available". OS/X has something similar to COM+ called CORBA which was left half-baked at best. Python is not .NET, sorry. Not anywhere near.
Someone may say the UNIX ideology is about your programs doing one thing at time, and having this STDIN->munch->STDOUT approach. But these streams never got any structure, and ppl out there been creating great tools to fill this gap, tools such as - jq, mlr, xidel to name a few. perhaps we should include ack, ag and rg in the list.
You know, guys, you hard-loving bash die-hards and sed+awk magicians, you should give this PowerShell thing a try before inventing the wheel again. And before legacies you wrote 20 years ago become as difficult to support as COBOL. Oh yeah, and PoSH is open source, based on open-source runtime, and available in brew/apt/yum...
Disclaimer: I do not work, and have never worked for MS (Guido does now!). Have used DOS since 6.22, FreeBSD since 8th version, Debian since v5, and Windows since v3.1. I did Perl for 20 years, actually I gave Perl classes in some university, still doing fair amount of Python, and accidentally discovered PowerShell 3 years ago. I'm not a .NET advocate, although I can tell the good parts.
What I was wondering though: can you easily access Powershell data types from python?
Also they squandered the opportunity to make the output interactive like with the Lisp machines. That would also have helped smooth the learning curve.
Making alternative implementations of the core utilities is only customary, but the curl name is is directly tied to the reputation of Daniel Stenberg, which is one of exceptional skill, integrity and attention to quality and security.
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 “include file relative to current script” (and not relative to current working directory), etc etc: anything that should’ve been simple and easy was neither.
I’ve stopped paying attention, so maybe they fixed this since then but it really wasn't a very well done system during its first decade or so.
For example `iwr` for Invoke-Web-Request.
Also the full names are only expected to be used in scripts to maintain readability. No one types that in the console. Also ALL Parameters can be abbreviated if they are unique. If no other Parameter starts with R then -R is enough for -Recurse. (there are some quirks with this, but generally pretty intuitive)
And using select or for-each on actual types is magical, instead of grepping/shedding/parsing a maybe standardized string, with completely unsensical names (like grep or sed)
If you give bash and pwsh the same time and love, they will become both pretty ergonomic
So, adding a new parameter starting with R to any command is a breaking change that will crash every script using it? Sounds like a terrible idea.
In a script, write it out in full. When manually typing it’s okay to take shortcuts. There is always a tension between ergonomics and safety.
man grep | grep -- --recursive
-r, --recursiveThey can also be abbreviated if they aren't unique, Powershell will just choose one for you. As an example:
> Get-Content $file -r
And we’re probably not getting there if people insist on cryptic shortcuts instead of semantic naming, just because they’re inclined to type everything out manually. It’s like those developers writing their code in Notepad++ and pretend that’s the way.
"Tooling" is a design smell. It's building hacks on hacks to make bad design and lack of understanding somewhat manageable.
For better systems all you need is a shell and a text editor.
That said, we do need a better shell. But definitely one with UNIX and CLI mentality.
Doesn't make "tooling" any less smelly though.
I think even unices have abandoned the UNIX philosophy and turned largely into "there's an app for that", so maybe there's not much interest for a better composable UI.
Why?
Text works. Text is the lowest common denominator for working with data. This is why terminals are still primarily text based. This is also why stdin/out/err are also commonly text based (when the user is expected to view it). Text is simple and easy to parse. Binary data exchange formats (or objects) come in and out of vogue, but text just keeps on working.
Text is a lousy abstraction. It may have worked well 50 years ago when computing was limited to researchers on American universities, but the digital world back then has little in common with ours.
Acting like extending the shell to anything beyond plain text would require switching to fancy new serialisation formats every other year is a red herring. The only thing it takes is admitting a shell isn’t used on typewriters but modern computers, where humans use high-resolution screens and programs can exchange structured data. Everything else follows, and is well suited for standardisation.
But that will never happen as long as grumpy sysadmins insist that cobbling together grep and sed in some arcane incantation is the only thing we ever need.
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 enshittified by corporate EEE with their badly overengineered enterprise crap. :(
I think the lack a structured (text based) format is a definite shortcoming in UNIX. Whitespace delimited lists of strings do get you surprisingly far (although some things are a total mess, e.g. filenames with spaces). But a simple more structured format (e.g. stripped down YAML with maybe non-prefixed lines being a list/iterator of strings for backward compatibility) would make the shell a lot more powerful.
You should be able to include binary in these, but make it render nicely in the terminal (e.g. like browser devtools do).
This doesn't also exclude having binary. And binary data is piped though programs all the time, but it makes including other data painful. Also don't see any harm in being able to show images in the terminal when wanted.
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 the data.
JSON (and XML and YAML and…) are all methods to try and adapt a text based data interchange format. And they all work roughly the same. You ultimately need some kind of processing library to full read them. But working with the data in any sort of structured context requires specialized tools (ex: jq).
Or you can still grep it, just like I do to manage my tab delimited data, and get part of the way.
I think the chaos of having no standard is kinda the point. Text is the lowest format that is easy for people to work with. We can visually parse it pretty easily, so the tools that support text can be pretty universal. Grep, sed, and awk can do a lot.
But to do anything more, you’re always going to need some kind of specialized parsing, even for tab delimited or CSV data. So, let the terminal work with generic text and be “good enough”.
As an example: you mentioned JSON and YAML and suggested a slimmed down YAML might be more powerful. I deal with columnar data with tens to hundreds of columns and thousands of lines. This wouldn’t work with either JSON or YAML… it’s too verbose. Instead I use (compressed) tab delimited text files for their ease of parsing in many languages. But those won’t work for many other use cases.
With data exchange, there is never going to be one right sized option for all needs. If you can accept that, then the “right” option is to choose none of them.
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.
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?
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).
Unfortunely taken away due to UNIX's free beer offerings.
The arrival of microcomputers, and horrors like Microsoft, were of course a major reason too.
The military wanted (!) to have better/cheaper generations of these computers for Research&Development and for deployment of applications. So it was decided to set up commercial companies: LMI and Symbolics were founded. LMI later sold a license to TI. The market for these machines was high-end: installations could cost anything from $50000 to $200000. In the first years these machines mostly went into military and government projects: military was sponsoring the deployment and first improvements (like the development of Lisp-specific CPUs).
Basically that's not unusual from many other government sponsored research, which later got marketed by a startup.
The Lisp they were using was standardized starting 81/82 (also with the help of Symbolics). This standard then was ported to PCs, Macs, Workstations and Mainframes. The Lisps were available free or commercial (a few hundred dollar to several thousand, depending on the vendor).
The Lisp machines itself remained tied to special hardware and mostly died in the late 80s and early 90s.
Various other free and commercial offerings of Lisp for PCs/Macs/UNIX systems died or survived...
The whole thing was initially financed by a large customer: the government (-> DARPA). This customer demanded commercial versions to be able to use them beyond the few prototypes. Roughly 10k machines (my estimate) were built and sold. At the same time cheaper Lisp systems were developed by universities and commercial competitors. Free / Open Source versions of Common Lisp (the Lisp dialect then also on the Lisp Machines) were developed by CMU (CMUCL), in Germany (CLISP, CLICC), in Japan (KCL), ...
Since when do bash/zsh offer a full sane programming language, not relying in external executables, a full blown language framework ecosystem, ability to load shared objects and importing public symbols as functions, and interoperate with D-BUS (as COM counterpart) as if client bindings were functions (again withouht external processes)?
Could be, but that wasn't the argument. The argument was, that fish has nice auto-completion, and that could be done without $irrelevant_feature_list.
(Also, by the same token, Powershell isn't Windows.)
> stating that Powershell just mimics existing popular bash/zsh means your not aware of Powershell capabilities versus bash/zsh.
So what does it better than bash/zsh in the area of code completion? Simple tab completion? For history, Ctrl-R and F7? Woo-hoo.
> Since when do bash/zsh offer a full sane programming language, not relying in external executables, (...)
Which is completely irrelevant when we are discussing code completion.
Powershell Core is less Windows, that I grant you.
As for code-completion, if you so insist, I don't see anything better on Fish that is so great about it.
I also don't install needless stuff like oh-my-posh, I don't need jumping rainbows and what not on my shell.
If Microsoft intends PowerShell to be combined with IDE-like features then they sure have a funny way of showing it.
Want to get an organisational unit from Active Directory? Turns out the command is Get-AdOrganizationalUnit. Discoverability is built in. All of the switches are the same. Is it -R or -r for recurse on the Unix command to list OUs from LDAP? What is the command name, anyway? I dunno, but I know the flag I need is -Recurse on Powershell.
Want to dump your DNS zones? Get-DnsServerZone is too verbose, obviously, so “cd /var/named/data && grep '\\(. *A *[0-9][0-9]*\\)\\|\\(..*CNAME..*\\)' db.*” is a much better option (‘scuse the escaping on that regex). Glad we could avoid the long command names.
Born of experience, maybe. Don’t know what the command might be? Get-Command dnszone* saves the day. I suppose I could ask GPT-4 for the regex for the bind dbs, otherwise. These are all things I can teach juniors in about fifteen minutes flat. You don’t need to learn three different Turing complete languages, all of which overload the same set of flags with different operations, just to run an operation against a bunch of files. Familiar, shorthand, and obtuse is not better just because it’s familiar.
Even if you set the colors, there's error/confirm messages that are Bold or ordinary yellow on white.
rm -rf in powershell:
Remove-Item --Recurse
But it gets better! (worse):
https://learn.microsoft.com/en-us/powershell/module/microsof...
>> Indicates that this cmdlet deletes the items in the specified locations and in all child items of the locations.
>> The Recurse parameter might not delete all subfolders or all child items. This is a known issue.
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 better for writing actual code, but the act of using it to do small interactive things is needlessly difficult.
This is why posix shells stick around I guess - they suck as programming "languages" but they're good enough to do the job, yet they're just really fast to use interactively.
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.
On OS/X you would need to look into Apple Scripting, XPC and Objective-C runtime, for a similar COM like experience, by the way.
The suggested alternative is the object oriented approach, just like PowerShell and the OP's project are based on.
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.
This is sarcasm, right?
Powershell structured pipe might look beautifully to architecture astronauts, but it is a step back.
The value of the component is the higher, the more components it can communicate with. Pure stream pipes in unices are the universal language; object pipes in powershell break the language in many incomprehensible fragments, and each component there needs "translator" for each specific fragment it can understand on input or output. Yes, it means that in the unix environment you may need some tool to be a middleman to extract only few things from the bigger stream; but these tools are also universal, unlike the need to understand specific piped object in the powershell world.
CORBA wasn't left "halfbaked". It was too complex for its own good, and unlike COM, there was nobody interested in pushing it further, so it was left behind. For a more lightweight messaging, there are XPC (macOS) or dbus (linux).
In 20 years when we use BGHY or whatever other format, we can use it alongside existing tools by simply... Making a tool that takes stdin in that format.
The idea of piping objects has been rediscovered many times.
(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 ;)
Of course - kudos for your efforts. Sadly went unnoticed for vry long.
I did several times over the years, but it simply didn't stick. If I have any non-trivial scripting tasks to do I run a Python or Deno script instead (at least those run anywhere, no matter if bash, zsh, fish, cmd.exe, PowerShell, and also run on any CI system without hassle).
(PS: I'm not actually a Bash diehard)
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.
I will give Marcel a try for sure, thanks.
To address one of your other comments: "but the former retains the compatibility with all the tools that don't know the structure."
Marcel plays nicely with host executables. The strings generated by an executable can be streamed into marcel commands. Marcel structured output can be piped into executables as strings.
Example 1: Compute distribution of word lengths. This pipes cat output into marcel commands:
cat /usr/share/dict/words | (w: (len(w), 1)) | red . + | sort
Example 2: Generate tuples of the form (i, i) and then have sed work on them.
gen 10 | (x: (x, x)) | sed s/5/xxx/g
[1] https://en.wikipedia.org/wiki/Marcel_the_Shell_with_Shoes_On...
For the website, I'm using wix. I'm open to suggestions for using wix better, or choosing an alternative.
I'm working on a not entirely dissimilar project (mine is focused more towards: fabric/ansible/cookiecutter type workflows, leaning on a lot of shell semantics. My workflows and hopefully soon documentation may be useful to you, I'd be happy to contribute them. I auto-build and publish releases to pypi. Project is: https://github.com/linsomniac/uplaybook
Been able to give poweshell commands in FOIA litigation and its power is on full display with one liners where it's hard for a gov agency to say no to something so simple.
Here’s FOIA request for the output of the command
find /home/jbiden -name “*secret*doc”
haha.
White House: We can’t do that.
Litigator: Can’t or won’t?
White House: either!
https://mchap.io/that-time-the-city-of-seattle-accidentally-...
Marcel is python-based. The nushell guys have had to invent a lot of language. By basing marcel on python, I don't have to invent language. Any logic to be added is expressed in python. E.g, do a recursive listing of files and find those that changed in the last 3 days:
ls -fr | select (f: now() - f.mtime() <= days(3))
Lots of marcel examples here: https://marceltheshell.org
sorry couldn't resist.
:)
OK, enough!
( ´ー`) ( ￣ー￣)ﾉ
find . -type f -mtime -3
ps -u djt | map (p: p.signal(9))
pkill -9 -u djt
ls -fr | map (f: (f.suffix, 1)) | red. + | sort
find . -type f | awk -F. '(NF>1){print "."$NF}; (NF==1){print ""}' | sort | uniq -c
This is a neat project though. I'll keep an eye on it.
As for a more complex example: yes, the website has better examples, but they are also more involved to explain.
Good example of why machine readable output is important. Agree that the tutorial should showcase more and larger such examples.
Only in some fairly esoteric environments: https://en.wikipedia.org/wiki/Filename#Comparison_of_filenam...
The larger bug in my example is that it fails if any of the directories in the path contain a "." in their name!
As someone who's leaned into Nushell deeply, I can tell you that the tabular and hierarchical data output is the major selling point of Nushell. For me and my team, who work with data and metadata constantly, it's an incredible productivity boost.
The major pains with Nushell are debugging pipelines that are too slow, having to learn the new language constructs, and process overhead for going in and out of Python for other pieces.
Can you expand on your first point? Why are tabular and hierarchical output so important for your work?
While taking an existing programming language like Python is an obvious choice (and one that's been made a bunch of times), I think that ultimately you need a language where something like a pipe (of objects or text) is not bolted on, but a natural consequence of a more general view of programming based on architectural interconnection.
"Pipes and filters" is an architectural style. And it is itself a polymorphic style, meaning there can be substyles that pass objects and substyles that pass bytes, substyles where the filters are processes and substyles where filters are components within a process.
So: good direction, more of this!
Looking for a compare/contrast, not a ranking. Diversity is usually good
Kudos to author, this looks really good
Integration with Python: Xonsh defines a language that is a superset of Python and shell, as I understand it. Marcel takes a different approach, defining only a bash-like shell language. Any customization is done in Python, delimited by parens. The separation between shell and Python is much stricter. Also, Marcel provides a Python API so that you can write shell-like marcel commands inside of a Python program. Shelling out from Python is notoriously ugly; the marcel API fixes that.
Sublanguages: In bash, there are lots of sublanguages, e.g. the arguments to 'date', awk, find, sed, and so on. Marcel's idea is to use Python as the sublanguage, because so many people already know it. I guess xonsh has a similar approach here.
Pipes: I think that xonsh, like more familiar shells, pipes strings. Marcel pipes python values in streams. So if you run ls, you don't get a stream of filenames, you get a stream of File objects, and you can operate on them downstream.
Database access: A stream of Python tuples is very similar to database query output. So database access is simple. There is an sql command which produces a stream of Python tuples. And a stream of tuples can be piped into the sql command, e.g. to populated a database.
Remote access: If you have a cluster, you can use marcel to upload a file to all nodes of the cluster, download from the nodes, or to execute the same command on each, streaming results back as streams of python tuples, each with an element identifying the node from which the data originated. I don't think xonsh does this.
https://marceltheshell.org has lots of information and examples of all this.
That's indeed much better, all those untyped strings in shells in a bad old design
Though hopefully xonsh will implement this as well https://github.com/xonsh/xonsh/issues/3967
It's more or less the same spirit as the Roddenberry estate allows someone to use the names - you are allowed to build a warp drive, as long as it warps spacetime and allows FTL travel.
I'm not sure that all applies here, but "Marcel the Shell" obviously belongs to and is associated with one specific brand, and the author of this nix shell is riding on that. It's not like when someone tries to trademark "Apple" in 2 different contexts.
A trademark claim here might not be dismissed under Rogers, but I don't think there is any jury that could ever find that consumers were likely to become confused about whether or not the command line tool Marcel the Shell was affiliated with the independent film cartoon character, and even if that could be established, unlike Jack Daniels, what $$$ damages were caused in trademark dilution? 3 figures?
Plenty of books, films, and TV shows have the same titles, which indicates that titles alone typically don't enjoy the protection of exclusivity.
Copyrighted characters and trademarks have a better chance of that, but those aren't being appropriated here, just the name.
"Marcel" is also a common first name, which makes it less likely that the creators of the film can claim any exclusive use of it, and "the Shell" is completely descriptive in this context, so unlikely to cause copyright issues.
However, instead of passing strings from one command to the next, marcel passes Python values: builtin types such as lists, tuples, strings, and numbers; but also objects representing files and processes.
It would be cool to be able to do this in regular Python programs. I know some libraries (like pandas) fake it by having a method return an object of the same class, allowing method chaining, but that doesn't work universally.
(1) making it possible to have any procedure that follows a certain interface to be usable as a "command" in the shell
(2) have a fallback function, that gives you a procedure for a standard shell command like 'ls' (or reimplement your own!)
(3) have piped commands automatically use lightweight processes (guile-fibers) to automatically parallelize work, if possible
(4) pass structured data instead of strings, unless the structured data is actually a string or a fallback command of standard shell is used (although perhaps one could write functions parsing that string output into structured data and have structured data at the next step ...)
(5) provide composition concepts, that make it easy to compose commands or pipe their outputs into other commands
(6) have readable arguments for things like input or output redirection
(7) no need to be POSIX compatible, I just want a useful tool for myself and anyone, who might want to try it at some point. Don't want to get mired in arcane stuff.
Well, many things to consider, probably tons of work hiding somewhere under the hood of all this. I also noticed there are issues with parallelizing things, if I want to keep the shell state local to a command. Previous commands in a pipeline would have to communicate shell state updates down the pipeline. So one needs to distinguish between communication of a shell state update and more input for the next command. Concurrency issues might ensue. I think I will be glad, if I can get some subset of my goals to work.
ls -fr | (f: (f, f.size))
ls -fr | select (f: f.suffix == '.py') | (f: (f, f.size))
ls -fr | select (f: f.suffix == '.py') | select (f: now() - f.mtime < days(1)) | (f: (f, f.size))
ext = (| e: select (f: f.suffix == '.' + e) |)
recent = (| d: select (f: now() - f.mtime < days(int(d))) |)
ls -fr | ext py | recent 1 | (f: (f, f.size))Similar for CSV.
If more programs adopt that pattern we could use stdout (fd1) only for interactive programs.
For this to work one would probably want to embed python and have a pool of interpreters so as not to pay the startup cost of python on every job invocation.
"That Said" I think passing around structures is not that useful to me - one is often trying to automate programs that are not written that way.
Python's pipe handling is complicated and horrible compared to bash and that's the thing I'd really want to "buy" from this - together with more shell-like ways to copy, search, touch files that are platform independent.
ls | map (f: f.size) | red + # this adds all the file sizes together
ls | map (f: f.size) | red (lambda acc,y: (y if not acc else acc+y))
BUT: how would I then divide the result by 1024? .... or assign the result to a variable?
There are a number of other functions one can use with "red" like concat, * (times), max, min, count, and, or and a few more.
At the moment I feel like I'm playing with a very fun toy that might give up on me at any moment and turn out to be limited. It obviously has limits but I'm really enjoying it.
ls | map (f: f.size) | red + | map (size: size / 1024)
ls | (f: f.size) | red + | (size: size / 1024)
ls | ... | (size: size / 1024) >$ x
x <$
x <$ (n: n * 1000)
This looks like an appealing feature! Having some more coreutils-like functions available in python (i.e., stuff that I wish was in the `os` module) would simplify some cases where I otherwise might have to resort to `subprocess` calls. The GPL license definitely narrows the number of situations where I would realistically be able to add this as a dependency, though.
As the author, a benefit it offers you is protection against someone selling your work or a derivative of it, or redistributing it with added restrictions.
From a user's perspective, the main downside is that using GPL software as a dependency makes the user's project a derivative work, which requires them to license their own project with the GPL (or from a selection of other compatible copyleft licenses).
In that sense it's considered a "viral license," i.e. everything downstream of the GPL software needs to adopt GPL. This is less of a problem for an application, but is more troublesome for a library (with many dependents of its own, with dependents of their own, and so on). It also means that if you use it in commercial software, you essentially need to open-source all of it.
So in your case, just using Marcel as a shell with GPL doesn't put any licensing obligations on the user, but using it as a library does.
I hope that helps! Someone else feel free to chime in if I misrepresented any of that.
> 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.
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).
Anti-copyleft is about taking these away. Sad how so many have eaten this corporate proaganda campaign.
Not only don't I have to get used to another language, I can lean on Python's rich ecosystem.
surprisingly works well.
now i can't stop doing it
Yeah. It works.
Love the fact that it uses Python!
I need to revise those, and images seemed like the way to get colorization right. I'll try to figure out how to do it with code blocks, it will hopefully be more maintainable. Cutting/pasting images is ridiculous.
No HN mods were involved.
Not seeing why my follow-up question itself was also downmodded.