Live data from Hacker News

Show HN: Lisp Shell

github.com

51–60 of 61 posts

Re: Show HN: Lisp Shell

#52
post #22

Earlier quoted context omitted.

With the major caveat that piping commands together doesn't work that well, eshell has been an amazingly useful feature of emacs for me. Combined with TRAMP support, it makes dealing with remote machines much much more friendly. As an example, "cd 'ssh:firstmachine|ssh:secondmachine:/'" works just like you would anticipate, bounces you through first machine to second machine. All commands from that point are executed…

> Even better, "cp someFile ~/" will transmit a file back to my local machine so that I don't have to work with the scp commands that it requires. Did not know that. That’s a neat trick! Do feel free to share more if you have any :)

Some time ago, I wrote a small blog post about that Tramp and remote editing files with eshell: http://200ok.ch/posts/edit-remote-files-with-emacs.html

Re: Show HN: Lisp Shell

#53
post #3

Fun Unix Trivia Time: Touch is supposed to update modified times. That it creates files when they don't exist is only the most common use, not the point of the thing.

I suppose this is a similar situation as with `cat' - it's meant to conCATenate stuff, but the most common usage I've seen (and one I've learned) is the idiom of `cat somefile | some-commands'. (Whenever I share a snippet with this idiom, I get told by one of my cow-orkers to stop abusing kittens...)

Isn't `some-command < somefile` more idiomatic (also, should spawn one process less)?

Re: Show HN: Lisp Shell

#54
post #53

Earlier quoted context omitted.

I suppose this is a similar situation as with `cat' - it's meant to conCATenate stuff, but the most common usage I've seen (and one I've learned) is the idiom of `cat somefile | some-commands'. (Whenever I share a snippet with this idiom, I get told by one of my cow-orkers to stop abusing kittens...)

Isn't `some-command < somefile` more idiomatic (also, should spawn one process less)?

Yes. See "Useless use of cat" (or "UUOC").

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:

  
instead of

  grep pattern file.txt
or

  cat file.txt | grep pattern

There are also some related useless uses, like useless use of grep | awk:

  grep pattern file | awk '{print $3}'
which can instead be written as

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

Re: Show HN: Lisp Shell

#55

Interesting but one nitpick: always, always, always, in the github readme.md put an example of use so I can see what it’s like before installing.

Agreed, I will update the readme ASAP with examples. This is my first post ever, and I didn’t expect such interest. Thanks a lot for writing.

Re: Show HN: Lisp Shell

#56
post #41

Earlier quoted context omitted.

'cd' is generally a shell built-in (even with Bash) rather than a forked command so I think it's fair if shell writers want to break the mold with that particular function. It's like how the shell built-in versions of 'echo' usually differ from /bin/echo (same for 'time' as well). 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.

I don't understand your argument at all. Whether something is a builtin or not is an implementation detail. 'cd' actually can't be anything but a builtin. 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'.

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

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.

Re: Show HN: Lisp Shell

#57

It would be nice to see some examples of the syntax, maybe a couple of simple scripts... 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!

Thank you for writing. Agreed, there a need for direction and better documentation. Feedback has been great and this has motivated me to work harder at this. I’d like to have something more standard. I currently use lsh to walk paths and record macros I use in IO tools for production.

Re: Show HN: Lisp Shell

#58

RASH, RAcket SHell library and language: https://github.com/willghatch/racket-rash Note: I am not the author

I started lsh a few weeks before finding out about Rash. I found it too complicated to be used as a replacement for sh, but I might not have read enough about it to make a proper judgment. In the end I wanted to implement something that behaved exactly like I'd expect to.

I'm late to the party, but I'm the author of Rash. Rash's documentation is terrible and out of date, but I've actually been planning to redo/improve all of the documentation within a week or two. I'm hoping that once I do that it will be much more approachable. Rash tries to allow both Bash style things and more normal Racket to be done with ease and mixed, and a lot of the complexity of Rash has to do with getting those two things to work together, and to allow lots of macro extensibility. But I think you'll find that it's quite powerful and useful... once I make it easier to make sense of.

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...

Re: Show HN: Lisp Shell

#59
post #23

You might be interested in an experiment of mine, https://github.com/tonyg/racket-something/blob/master/src/so... , which combines an indentation-based reader with a handler for unbound variables to permit fluid interoperation between Racket procedures and external programs. Here's an example ( https://github.com/tonyg/racket-something/blob/master/exampl... ): #lang something/shell // Simple demos ls -la $HOME | grep…

I figured out a way to combine indentation-based syntax with S-expressions too http://text.cirru.org/

Re: Show HN: Lisp Shell

#60

Earlier quoted context omitted.

I started lsh a few weeks before finding out about Rash. I found it too complicated to be used as a replacement for sh, but I might not have read enough about it to make a proper judgment. In the end I wanted to implement something that behaved exactly like I'd expect to.

I'm late to the party, but I'm the author of Rash. Rash's documentation is terrible and out of date, but I've actually been planning to redo/improve all of the documentation within a week or two. I'm hoping that once I do that it will be much more approachable. Rash tries to allow both Bash style things and more normal Racket to be done with ease and mixed, and a lot of the complexity of Rash has to do with getting t…

Hi there, thanks for replying. I’m quite sure Rash is superior to my toy program, tbh I can’t wait to read more about it and check your code. If I have some free time I’ll try to contribute too. Cheers!
Post reply on HN