terrycojones / daudin Goto Github PK

What you have here is amazing! Someday daudin can replace bash..., maybe rename it to pysh or something like that.

Just started experimenting with daudin & I'm enjoying the shell, python mix. This is really nice.

In the past I've also looked at pipeline oriented tools like pyp and piep.

The one thing that is immediately missing seems to be zsh's search through history. Typing part of a command and then up arrow through the matches is a major part of my day. Is this replicable?

It is good to see someone trying to innovate in the space of develop tools. But duplicate efforts could be avoided. There is xonsh which is a superset of Python. It does define some extra constructs but very minimal. How does daudin compares to xonsh?

I don't know why, but when I run ls alone on a line (in my daudin directory) a TAB is in the output. The ls runs in a pseudo-tty and it seems that a TAB really does come back from the master pty desciptor. So I must be doing something wrong somewhere. This doesn't apply when ls is piped into another command because in that case a pseudo-tty isn't used. The ls output prints just fine with the embedded TAB, but how did it get there? It's hard to figure out what's going on because you can't just pipe into something (like od -a) from the shell because then ls changes its behavior. Can it be that there really is a TAB in the ls output in a pseudotty?

Do you think there will ever be a stand alone version of this? Also, this is AWESOME.

I only notice this when I exit back into fish and type mv (on typing the space the command line jumps around slightly and it's hard to see what you've typed). It doesn't always happen. It's weird because the code that fiddles with the terminal is in a try/finally block in daudinlib/pipeline.py.

Thank you for this great shell!
Two ideas:

1. Why not add the option to use --shell=False for running system commands without a shell e.g. subprocess.run(... shell=False)
   The scripts would be more portable, faster and less error prone and best of all you can forget about all the shell idiosyncrasies like shell escaping etc ... and error handling would also be much easier.
2. If you have fish installed it's easy too add fish completions as an option for system commands and arguments (for example the clojure shell does this):
   https://github.com/dundalek/closh/blob/master/resources/completion/completion.fish
   Adding this as an option would make this shell as convenient as fish!

Just have one sub-shell and send commands to it instead of forking a new one for each command. That would allow persistent shell variables.

I have created a project that does this: https://github.com/NightMachinary/brish
It's pretty much as easy as this:

from brish import z, zp

z('echo {python_command_here_that_gets_quoted_automatically(...)}')
zp("echo zp is like z but prints the result's stdout in addition to returing a CmdResult")
zp("echo :e disables quoting {'$test1'} {'$test2':e}")

They accept fork=True to fork, but by default don't, so variables persist.

The following ZSH syntax is failing and I don't understand what the debug message is saying.

>>> foreach x ({2015..2019})
                    Processing 'foreach x ({2015..2019})'.
                    Not in pipeline.
                    Trying eval 'foreach x ({2015..2019})'.
                    Could not eval: invalid syntax (<string>, line 1).
                    Trying to compile 'foreach x ({2015..2019})'.
                    SyntaxError: invalid syntax (<input>, line 1).
                    Trying shell 'foreach x ({2015..2019})' with stdin ['/bin/sh: 1: Syntax error: "(" unexpected'].
                    In _shPty, stdin is None
/bin/sh: 1: Syntax error: "(" unexpected
                    Shell returned '/bin/sh: 1: Syntax error: "(" unexpected\n'

I ran vim in daudin to see how it would go. All went well until I exited.

>>> vim Makefile 
Traceback (most recent call last):
  File "/home/terry/s/me/daudin/daudinlib/interaction.py", line 58, in runCommand
    nCommands)
  File "/home/terry/s/me/daudin/daudinlib/pipeline.py", line 128, in run
    handled, doPrint = self._tryShell(fullCommand, print_)
  File "/home/terry/s/me/daudin/daudinlib/pipeline.py", line 238, in _tryShell
    result = self.sh(command, print_=print_)
  File "/home/terry/s/me/daudin/daudinlib/pipeline.py", line 283, in sh
    return run(stdin, *args, **kwargs)
  File "/home/terry/s/me/daudin/daudinlib/pipeline.py", line 374, in _shPty
    return ANSI_esc.sub('', result.decode('utf-8')).replace('\r\n', '\n')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xbd in position 145: invalid start byte

I have a feeling we should just silently (unless debugging is on) swallow such errors. It would be good to know why this one happens and fix it, but OTOH we probably don't want all the data that vim writes to the terminal to be stored in the _ pipeline variable. But how to distinguish with cases we do want, e.g., when running ls?

Is this possible? I can't remember all the methods and attributes I need.

Hi @terrycojones! Following #6

Daudin was really me playing around to see what I could come up with.

Your vision of pipelines and shortcuts around _ look interesting. It will be cool if most of useful approaches not stay just a fun and sometime would be packed as a xontrib for xonsh. It has bigger community and your most greatest ideas would be supported.

Thanks!

UPD: ⭐️ The solution for xonsh — xonsh/xonsh#3366 (comment)