7 ms·

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

• riedel 3y ago
  I was immediately thinking powershell. I have been doing some Powershell scripting for building chocolatey packages: it weirdly did not feel like shell though and my muscle memory of POSIX commands fails me on the terminal I guess. What I was wondering though: can you easily access Powershell data types from python?
• Tabular-Iceberg 3y ago
  I hear you, and I have tried it, but the commands feel gratuitously different to me. Also they squandered the opportunity to make the output interactive like with the Lisp machines. That would also have helped smooth the learning curve.
  • buildartefact 3y ago
    The worst part of it is they aliased a bunch of common posix command names to their power shell equivalents but then they have different flags or semantics. Works fine until it trips you up destructively.
    • Tabular-Iceberg 3y ago
      They even made their own broken curl, which to me is straight up trademark infringement (ethically speaking at least, IANAL) 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.
• skrebbel 3y ago
  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 “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.
  • anticrymactic 3y ago
    While I tend to agree, a lot of commands also have pretty good aliases. 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
    • Maken 3y ago
      >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) 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.
      • Pet_Ant 3y ago
        > So, adding a new parameter starting with R to any command is a breaking change that will crash every script using it? 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.
• eviks 3y ago
  You're right on the text vs structure point, but then pwsh is unfortunately slow and unergonomic enough that makes the transition from a better modern shell (so, not bash) harder, especially with a better and more common language like python
  • bayesianbot 3y ago
    Have to agree with the slowness, I just used powershell for a month or two and thought it's great.. Until one day I accidentally started fish and it felt so blazingly fast that I couldn't go back to pwsh anymore..
• kunley 3y ago
  Am I the only one who actually gave Poweshell a try and found it to be a nightmare?
• pjmlp 3y ago
  For all the praise it gets, PowerShell is basically the REPL environment from Xerox PARC (Smalltalk/Interlisp-D/Mesa/Cedar), ETHZ(Oberon), Lisp Machines, finally making into mainstream computing. 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.
• mgaunard 3y ago
  sed and awk are simple tools; choosing an entirely different non-standard tool just because you can't learn them seems a bit overkill.
  • feldrim 3y ago
    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.
    • geophile 3y ago
      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.
      • mgaunard 3y ago
        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.
        • geophile 3y ago
          Yes. They work with lines and words, but the sublanguages are hideous.
    • mgaunard 3y ago
• vetinari 3y ago
  No. 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).
• porridgeraisin 3y ago
  Today, we use json. How do we integrate it into our shell scripts? That's right, we simply make a tool (jq, miller) that takes stdin json, and _continue_ to use the agnostic, untyped tools alongside it, because they are just that, agnostic. 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.
  • geophile 3y ago
    But it still sucks because of the unstructured data. I added JSON support to Marcel in an afternoon, and still have structure data flowing through the pipelines. JSON first, then nested Python ducts and lists from the JSON translation.
• geophile 3y ago
  I wrote Marcel, and its forerunner osh, also recently on HN. Osh actually preceded powershell, and in fact I don’t recall it receiving any acknowledgement from Microsoft. To be fair, I’m sure they never heard of it. The idea of piping objects has been rediscovered many times.
  • larodi 3y ago
    You are missing part of the picture. Object tossing is one thing, having access to the plethora of apis you get from Com+ and .net in a finger snap is another. Of course - kudos for your efforts. Sadly went unnoticed for vry long.
  • mst 3y ago
    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 ;)
    • geophile 3y ago
      Sorry, osh as in object shell: https://github.com/geophile/osh https://github.com/geophile/osh.
      • mst 3y ago
        Aha! Thank you!
• flohofwoe 3y ago
  > 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. 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)
  • liotier 3y ago
    Except when scripting Microsoft products, for which one might prefer a Powershell library.
• kunley 3y ago
  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.
  • geophile 3y ago
    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.
    • kunley 3y ago
      Yeah, ok that's a valid view. I will give Marcel a try for sure, thanks.
      • geophile 3y ago
        Cool. 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 (Or you could replace cat by the marcel command "read".) 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 The (5, 5) tuple is replaced by (xxx, xxx)