anki-code / xonsh-operators-proposal

Proposals of the new logic for xonsh operators.

Xonsh Enrichment Proposals (XEP)

Creation Date	State	Link	Description
2023-01-25	Concept	No page	Use back quotes for glob instead of regex.
2020-10-30	Ready to review	XEP-2	Better alternative to XEP-1 that based on the idea of one operator.
2020-10-24	Stopped	XEP-1	Based on the idea of three operators.

Links

• PEP 1 -- PEP Purpose and Guidelines

xonsh-operators-proposal's Issues

Using CP.out

In regards to XEP2:

1. Remove trailing new lines in CP.lines.

Maybe add that this will also affect iterating over a CP object? (for line in $(...):)

2. Add str representation as "\n".join(CP.lines).

Do you mean str($())? Also, why not have it return CP.out instead of joining the lines?

3. Add CP.str property to short access i.e. name = $(whoami).str

This already exists as CP.out.

Note that CP.output is lazy and doesn't force the command to end, whereas CP.out waits for the command to wait so it is the real complete output and should generally be used instead of CP.output.

4. Optionally. Add CP.o property as shortcut to access to output.

Like I wrote, this exists as CP.out.

5. echo -n @($(curl https://xon.sh).output) | wc -c and html = $(curl https://xon.sh).output need to use CP.out instead.

How to get the complete output?

I noticed there's no way in XEP-2 to get the output of a command without stripping because

Remove trailing new lines in CP.out

How could a user get the complete output?

Maybe the stripping should only occur in str(CP)? this way $() in subproc is the same as @($()) (which becomes @(str($()))), and the complete output can be retrieved via $().out, which won't break current usages.

Unexpected new line in CP.out on xonsh2 fork

hi, first of all, thanks a lot for these changes to xonsh. I'm currently trying out xonsh and was very disappointed in the default $() behavior, which needs a lot of stripping.

currently I'm trying out some scripts, but a weird thing is happening which I don't really understand. Not sure if its even related to the changes in this fork.

t1 = $(curl -Ss https://p.krebsco.de/029cwqk).out
t2 = $(curl -Ss https://p.krebsco.de/029cwqk)
t3 = t2.out

t1[32760:32790]
output: ': "http:/\n/rss.r/?action=displ'
t3[32760:32800]
output: ' "http://rss.r/?action=display'

why is there an erronous newline in t1? this sadly breaks the json and makes json.loads error with

json.decoder.JSONDecodeError: Invalid control character at: line 922 column 28 (char 32769)

hopefully you can help me figure this out

EDIT:
this problem does not appear in normal xonsh with !()

Update "Re-thinking the command substitution operators" issue

@daniel-shimon please update the Re-thinking the command substitution operators issue by XEP-2 proposals.

Whitespace-separated arguments

Hi @anki-code!
First of all, really nice work with this repo!

You've clearly put a lot of time and effort into this and I think it really raises the level of the discussion 😄

In the XEP2 proposal, you wrote about whitespace splitting:

Probably we can replace it to something like @($().words). I suggest to think about dropping @$() on final stages. Feel free to create an issue for talking.

So I created an issue to talk about it :)

You write about line-separated arguments in the use cases table:

Use case	Subproc current / proposed	Python current / proposed
Get multiple arguments. ✅ Becomes shorter.	du @($(ls).rstrip().split('\n')) du $(ls)	files = $(ls).rstrip().split('\n') files = $(ls)

Could you add a row about whitespace-separated outputs as well?
For example:

groups
# daniel adm dialout cdrom floppy sudo audio dip video plugdev netdev docker

pkg-config --libs libuv
# -luv -lrt -lpthread -lnsl -ldl

(pkg-config's output is used for compilation and has to be passed with each value as a different argument to the compiler).

How do you think these should be handled? We should decide it in this XEP IMO for completeness.

I currently think @$() should stay as-is, currently it's just handy syntactical sugar and can remain so after the XEP.

To research: merge $() and !() into one $() and remove !()

Can we use one operator $() and completely remove !() by moving the !() object functionality to $()? It looks interesting because in subprocess mode the !() operator always used with python substitution i.e. @(!().split()). Is there a way to remove !() and do @($().split()).

Anthony also wrote:

I am in favor or removing syntax at this point, rather than adding. I really want to avoid the issues that Bash has where there are so many specialized syntax elements that no one can remember them. Xonsh should be easy for people to learn and use and consistent in its implementation.

Related:

What happens with the other subprocess operators depending on their calling modes: ![], !(), $[]

What about leading and trailing whitespace around the $() operator?

The original question from laloch:

What about leading and trailing whitespace around the $() operator? Can you do mkdir -p /tmp/$(whoami)/garbage?