Here's an example (https://github.com/tonyg/racket-something/blob/master/exampl...):

  #lang something/shell
  // Simple demos

  ls -la $HOME | grep "^d" | fgrep -v "."

  ls -la | wc -l | read-line |> string-split |> car |> string->number |> \
    printf "There are ~a lines here." | sed -e "s: are : seem to be :"
  (newline)

  def ps-output
    pipeline
      ps -wwwax
      preserve-header 1 {: grep "racket" }
      space-separated-columns [string->number]
      |> csv-expr->table
  print ps-output

  def message-box text:
    whiptail --title "Testing" --ok-button "OK" --msgbox text 8 50

  message-box "This is pretty cool."

(EDIT): Here's a screencast of an interactive session with the shell. Very simple, but shows some of the basics: https://asciinema.org/a/83450

So in that regard I don't think it's fair to compare 'cd' to 'cat' nor 'touch' where people will be used to the GNU / whatever coreutils.

The behavior of 'cd' is defined by the Posix standard (in spite of it needing to be a builtin). Now, you're welcome to care or not about that. But there's no reason to make that decision inconsistently for 'cd', 'cat' and 'touch'.

I sense you're misunderstanding something, namely that POSIX defines not only the names and behavior of a number of common utilities, but also the shell language. There is no "in spite"; POSIX defines the shell syntax features like while, case, if, the various expansions that the shell does and so forth.

By your reasoning, someone's original shell-like scripting language must not have a case statement that is not terminated by esac, and that doesn't have cases terminated by ;; because POSIX requires these. I.e. one mustn't develop a program and call it a "shell" if it isn't a POSIX conforming shell.

cd is a shell feature like while or case; it's effectively a special assignment operator for mutating the shell's current working directory.

My point being shell builtins can and often do differ from one shell to another.

> Whether something is a builtin or not is an implementation detail.

You could argue that but I think it goes a little beyond purely implementation detail. A builtin is often a builtin because it fits the shell idiom better than having a forked command. eg `time` wouldn't work well if you had to put the command you want timed in quotation marks; which is one of the reasons Bash includes it's own `time` function as a builtin despite `/bin/time` being arguably more powerful (there are other reasons but I feel this is going to be a lengthy reply and `time` vs `/bin/time` is already well documented online anyway)

Thus if this shell's idiom is simplicity over features then it makes some sense not to follow Bash's convention for `cd`. In fact if I can use myself as an example; I have also written my own shell I didn't follow Bash's convention for `cd` either (which means I'm also aware `cd` cannot be anything other than a built in :P) The reason I broke compatibility with `cd` was because I wanted historic directories in a stacked array by default; I don't support `pushd` / `popd` because `cd` does it right out of the box. The historic variable holds the previous directories in a JSON array and that better fits the idioms of my shell because my shell is designed around natively munging data structures such as JSON. Thus my builtins should also follow the same idioms as the rest of the shell regardless of whether that breaks POSIX compliances or not.

> The behavior of 'cd' is defined by the Posix standard (in spite of it needing to be a builtin).

In case you hadn't noticed, this isn't a POSIX shell. There's no law stating every $SHELL has to be POSIX compliant and in fact a lot are not; including Bash itself. So your point about POSIX compliance is not relevant here at all as if you want a fully POSIX compliant shell then you should be looking elsewhere.

> Now, you're welcome to care or not about that. But there's no reason to make that decision inconsistently for 'cd', 'cat' and 'touch'.

Again I feel the need to reiterate the point that one runs a different shell because they lean towards a different idiom. So with that regard there is every reason to make a decision for breaking standards on `cd` if those standards don't conform to your shells own idioms. Otherwise what the hell is the point of running an alternative shell?

I feel `cat` and `touch` are exceptions to this rule because they are traditionally forked. I mean by all means the author is welcome to re-implement some of coreutils as well if they wish (ala Busybox) but I personally feel that is a step too far in shell design (excluding for a moment my previous example of Busybox as that is clearly intended as a one stop shop and is very useful in that regard!). I think the saner approach if you want to offer alternative functions to coreutils is to offer alternative builtins (eg `lcat` for "Lisp cat"). However that is my personal preference and if this particular shells author wants to reimplement coreutils for whatever reason they choose then I wish them luck. If nothing else, it will teach them a new appreciation for GNU et al coreutils.

I absolutely encourage that! I accepted that possibility in my comment. See the kind of stuff I build: https://github.com/akkartik/mu. I introduced Posix purely as an example that builtins are as subject to standardization as coreutils.

Other than clarifying that I'll agree to disagree. It's great to rethink a shell from the ground up. If you're doing that, what earlier shells happen to choose as a builtin is an irrelevant signal. Depending on how you design your idioms, it may make sense to override stuff from coreutils as builtins. As you've pointed out, such overriding has already happened in bash and other shells.

These are all artificial boundaries to be questioned. Decide what behavior you want to copy and what you want to rethink regardless of where you find it.

It's pretty clear this shell isn't intended to follow in the footsteps of Bash, let alone be fully POSIX compliant, so I don't really understand why you are comparing it to them in terms of compatibility (and even more confused now that you've said you encourage people breaking POSIX).

Or is the point you're raising a question of what should be a builtin and what should not?

(happy to agree to disagree by the way; but I'm just a little confused as to what we are disagreeing about :))

Set aside my mention of POSIX as a minor point. My basic claim is this: building a whole new shell is an ambitious act. Whether your goal is to create a better experience for others or just learn new skills, restricting yourself to what earlier shells happen to consider to be builtins is limiting ambition. Be more ambitious and rethink as much as you want.

I'm not saying you have to rethink everything all at once all the way up from machine code (though I'm sympathetic to and experienced in that particular failure mode ^_^). I'm saying if you have an idea to improve 'cat' to fit better with your new shell, the fact that it's in coreutils shouldn't cause you pause. Who cares if it's a builtin in bash or not? Make it a builtin in your shell.

In which case, uh, you want the current functionality.

- "cd -" has no interaction with the pushd/popd stack except in the sense that it alters the top of the stack (the current working dir). It doesn't swap the two top entries of the directory stack, but swaps the top with an off-stack saved location ($OLDPWD).

- "pushd" with no arguments swaps the top two stack entries.

(Whenever I share a snippet with this idiom, I get told by one of my cow-orkers to stop abusing kittens...)

If you prefer to have the command arguments at the end of the line (so it's easier to amend), you can do e.g:

  < file.txt grep pattern

  grep pattern file.txt

  cat file.txt | grep pattern

  grep pattern file | awk '{print $3}'

  awk '/pattern/ {print $3}' file

From the readme I don’t quite understand the purpose of lsh, though. Usually, a shell allows you to run programs and manipulate their environment. However, lsh seems to reimplement some commands like find or rm and does not provide operators to manipulate the runtime environment like redirecting output. Maybe you can write in the readme your goal: play with racket, have a shell that accepts racket forms or something different.

E.g., the README states that 'cd/' is an alias for '(cd "/")' which seems to imply that one has to wrap every command in '()' and quote every filename... not very practical for a shell!

(pmap (lambda (f) (run (+ "[some-command] " f))) (directory-list))

...and run any binary against all files in the current directory, in parallel. (directory-list) returns a list of files and one can run any Racket function against that list. It's also possible to gather any command output and pipe it back to Racket for processing. I'm working on a more polished build with better docs.

  I'd like to cover the minimum (like running binaries directly instead of having to use run). I've only begun to think about everything that's needed to bring this to its full potential.

  I'll also check the other projects I hadn't heard of, maybe some of them are already far better than mine :)

Did not know that. That’s a neat trick! Do feel free to share more if you have any :)

I did have to add a lot to my tramp path. Can't remember why, right off. I just know that it helps find a lot of things that don't make the standard path for some reason.

$ (defun sq (x) (* x x))

$ sq 5

25

More often than not it's easiest to just use the Common Lisp functions for creating directories and interacting with the system, but when that doesn't work, I have a function similar to this one in my .sbclrc file:

(defun run (cmd) (with-output-to-string (outs) (uiop:run-program cmd :output outs)))

At work, I've even created a small Common Lisp library for calling our JSON APIs over HTTPS and running commands on our test clusters using SSH. It's all tightly integrated into Emacs, and I can use it do things like open remote files in my local Emacs.

Note: I am not the author

Of course I'm also happy for anyone to make a new shell that they like and want to use themselves. I did it, after all...

    (set-macro-character
     #\$ #'(lambda (stream char)
             (declare (ignore char))
             `(uiop:getenv ,(symbol-name (read stream)))))

"Who should I thank? My so-called "colleagues," who laugh at me behind my back, all the while becoming famous on my work? My worthless graduate students, whose computer skills appear to be limited to downloading bitmaps off of netnews? My parents, who are still waiting for me to quit "fooling around with computers," go to med school, and become a radiologist? My department chairman, a manager who gives one new insight into and sympathy for disgruntled postal workers?"

and concludes:

"Oh yes, the acknowledgements. I think not. I did it. I did it all, by myself."

http://philip.greenspun.com/wtr/dead-trees/acknowledgments.h...