Rashi Plus Plus - the new Hebrew scripting language
A deep learning project/library in python
Inspecting a live KVM-based virtual machine
daniel-shimon/char-rnn-tensorflow 1
Multi-layer Recurrent Neural Networks (LSTM, RNN) for character-level language models in Python using Tensorflow
HTML Parser and renderer in cpp using the SFML rendering library
A keyboard and mouse logger using winapi
daniel-shimon/snake-evolution 0
A virtual arena teaching Neural Nets to play using a genetic algorithm.
Python-powered, cross-platform, Unix-gazing shell
issue commentxonsh/xonsh
Re-thinking the command substitution operators
As of now, I have two issues with @anki-code 's proposal:
- No clean solution for
no split, strip newline. For me at least, this seems to be the daily usage. - I'm not convinced the custom
OutputLines's benefits are really worth it. In my experience at least, customized hybrids like this do more damage than good in the long run. They're hard to maintain, they surprise users and require a large learning curve.
Then again, I don't have a lot of experience in the shell business 😸 @scopatz I'll appreciate your view on these issues if you have the time. I don't have a super strong opinion here, these are just my thought in the current state of things.
comment created time in an hour
issue commentxonsh/xonsh
Re-thinking the command substitution operators
But you mean under this sentence - different from current xonsh behavior
You're right, changed it.
In bash if you call $(uname) the result will be the same as in my PR.
Agreed.
What I'm saying is that if we think about the real intent when using commands like uname, hostname etc, you want the content, not lines. This is why they're in the No split section in the examples.
The fact that their output has an extra newline is because unix tools always append it regardless of the tty. It doesn't mean you want to split them by lines.
The meaning of this two point is similar. Please unite it into one.
They're two different things:
OutputLinesis a new thing users need to learn.- The fact that sometimes it works like a string makes it a really error-prone subtelty in my opinion. Since this is more of a feeling than a backed-up clame I'll remove it :)
We need a copy-pastable pack of examples (use cases) that show how every approach works
I prefer this format. There's one table that shows all the examples we have, and a table for each proposal with their solutions per scenario. It's a bit less clean but provides the entire scenario. I'll try to make it a bit more readable though :star:
Also you completely miss the logic from my PR about consistent operators
I don't, it's in the table in your proposal.
Maybe It's a good idea to show how sh-shells solve the same use cases
I do, see Current state and comparisons with other shells
Please mark this bullet point by prefix "[Reported to PR author, waiting for confirmation or solution]".
This whole thing is just a draft, and I'll update the proposal when you'll come up with a solution, promise.
Is not working cute in subproc mode. You should do du -sh @($(ls).iter) (or similar).
Whoops, typo!
That was meant to be !().__iter__, meaning iterating over CommandPipeline like you saw happening with @(!()) and list(!()).
The CommandPipeline class is iterable and returns list of lines with trailing new line symbol (that should be stripped again if we want to use it as arguments 🤦). This strange behavior should be mentioned in description.
It is - that's what I meant in the second bullet of adqm's approach (the typo above).
comment created time in 2 hours
issue commentxonsh/xonsh
Re-thinking the command substitution operators
@anki-code I updated the description 👍
On another note:
Returning a list in python mode beats the simple intuitive meaning of $().
Absolutely no. The
$()is a substitution operator in other shells and it's absolutely expected that$()will substitute arguments list.
What I mean is that the splitting by lines is unintuitive and unfamiliar for the default $() implementation.
Most of our examples come from the upper-left corner of the usage scenario - No split, Strip newline.
In this regard, I feel that your proposal does too much magic for these cases. You're splitting by lines even though that's not what a user intends to do when using commands like uname.
The PR assumes that these commands will always contain one line, so the user's intent will align with OutputLines behavior.
This is the reason as of now I agree with @adqm the most.
We already have line splitting with !().__iter__.
If it will strip the trailing newlines (e.g. use .splitlines()), in conjunction with $() stripping the trailing newline we will easily have all three major use cases:
- Strip trailing newline, no split
$() - Strip and split by newline
@(!()) - Split by whitespace
@$()
comment created time in 14 hours
issue commentxonsh/xonsh
Re-thinking the command substitution operators
Hi @adqm, thanks for the detailed explanation! A few questions:
I think it makes the most sense for $(...) to return a string with trailing newline stripped
- Do you mean to exclusively strip one trailing newline or all of them?
If you want the result as multiple arguments split by newlines, you can do command @(!(...))
- Currently each line returned here contains it's trailing newline. In light of this discussion, don't you think these newlines should be stripped as well (like
str.splitlines())?
If that deleted some whitespace that you wanted, you have to type a bit more, but you can do !(...).out
- What about having
!()return the entire output in command mode? I personally think it's inconsistant with@(!@()), but I want to hear your opinion.
comment created time in 14 hours
issue commentxonsh/xonsh
Strip away newlines in subcommand output `$(...)`
I agree we should improve the efficiency of the discussion, and document all the arguments in a centralized way.
Following what you guys said, since this is such a major design decision in xonsh I suggest we take a step back from implementation details, gather concise examples, compare to other shells and document the pros-and-cons for each proposal.
I'll try to make this issue a mini-PEP for the subject. @scopatz if you prefer some other medium, a separate repo could be cool.
I've updated the description to express all the things we've talked about. @anki-code @laloch please let me know if I missed stuff and give us more examples so that I'll update the description.
Let's take a few days to get more examples, discuss more options and let more people from the community express their opinions :smile:
comment created time in 21 hours
issue commentxonsh/xonsh
Captured subprocess attributes not queryable until result is evaluated
@shahinism as I understand it, this issue is with .output specifically since it's supposed to be lazy evaluated
Could you try the same with .out?
comment created time in 2 days
pull request commentxonsh/xonsh
@anki-code so does $() return a list in python mode? This means stuff like name = $(whoami) won't work at all, I'm not sure that's a good thing
comment created time in 2 days
push eventdaniel-shimon/xonsh
commit sha 12181630f64c5ed051c3be3a5fe02dcbd77ea683
procs: Add CommandPipeline.raw_out for retreival of the raw stdout bytes
push time in 2 days
push eventdaniel-shimon/xonsh
commit sha 6a96cf18a9418291cb8b6bdfdf34aa623eddace7
procs: Add CommandPipeline.raw_out for retreival of the raw stdout bytes
push time in 2 days
issue commentxonsh/xonsh
Strip away newlines in subcommand output `$(...)`
@anki-code very nice!
Can you clarify that the behavior should be .rstrip('\n) like in other shells?
Also can you add the make - j $(nproc) example?
comment created time in 3 days
issue commentxonsh/xonsh
Strip away newlines in subcommand output `$(...)`
@scopatz In this suggestion, the !() operator doesn't really act differently wrt to the current mode, it just returns a helpful thing in subprocess mode and returns the complete CommandPipeline object in python mode.
comment created time in 3 days
issue commentxonsh/xonsh
Strip away newlines in subcommand output `$(...)`
@anki-code if I understand correctly with your suggestion $() isn't modal?
Meaning $() always returns the rstripped output, and !() returns the complete output in subprocess mode and a CommandPipeline object in python mode?
This sounds like a pretty good idea to me - !() is used for a fine-grained usage and $() just works for substitutions.
comment created time in 3 days
pull request commentxonsh/xonsh
procs: Add CommandPipeline.raw_out for retreival of the raw stdout bytes
Thanks @daniel-shimon! This is a great feature! For completeness, there should probably also be a
raw_errinterface.
Done
Could you help me decipher the error in the tests? It doesn't happen to me locally :(
I'm getting Command '['echo', 'hi']' returned non-zero exit status 1.
comment created time in 3 days
Pull request review commentxonsh/xonsh
procs: Add CommandPipeline.raw_out for retreival of the raw stdout bytes
def tee_stdout(self): enc = env.get("XONSH_ENCODING") err = env.get("XONSH_ENCODING_ERRORS") lines = self.lines+ raw_lines = []
Done
comment created time in 3 days
Pull request review commentxonsh/xonsh
procs: Add CommandPipeline.raw_out for retreival of the raw stdout bytes
+"""
Done
comment created time in 3 days
push eventdaniel-shimon/xonsh
commit sha 813376da43db959a150883c76384611c6e4dacf0
procs: Add CommandPipeline.raw_out for retreival of the raw stdout bytes
push time in 3 days
push eventdaniel-shimon/xonsh
commit sha 2a65885f884c4815b407eb5b465dcb8560ca6a6d
procs: Add CommandPipeline.raw_out for retreival of the raw stdout bytes
push time in 3 days
issue commentxonsh/xonsh
Strip away newlines in subcommand output `$(...)`
I like this logic when I thought about users from bash world and fast diving into xonsh. Looks consistent.
It's not just for users coming from a different shell, it's really more useful and intuitive since you want information from some standard unix command (e.g. whoami, uname, nproc etc), and they all append newlines to their outputs.
Here's another example from a classical daily shell use - make -j $(nprocs) fails. Yeah, you could use @$() but it doesn't really express what you want (stripping, not splitting), and I don't think this kind of simple classic shell usage should cost a lot of syntax overhead.
comment created time in 3 days
push eventdaniel-shimon/xonsh
commit sha d85ed4a3406da763b2c32e283e1870ec484670e3
procs: Add CommandPipeline.raw_out for retreival of the raw stdout bytes
push time in 3 days
issue commentxonsh/xonsh
Strip away newlines in subcommand output `$(...)`
Yeah I agree about not adding more syntax in this area
comment created time in 3 days
issue commentxonsh/xonsh
Strip away newlines in subcommand output `$(...)`
Another option is to only have $() strip the trailing newlines, while !() doesn't.
This way $() is robust for day-to-day command substitution but for full accuracy one can use !().out.
This resonates with $() being intended for simple usages (you can't use it to get the exit code etc), so I think adding the rsplit to make it more robust and useful is pretty sound
comment created time in 3 days
push eventdaniel-shimon/xonsh
commit sha 031d75a8aa1d8f245064c265876771b73370f8cd
procs: Add CommandPipeline.raw_out for retreival of the raw stdout bytes
push time in 3 days
push eventdaniel-shimon/xonsh
commit sha feea8ff9df0e8c5b58a0763d5507caf27085aa85
procs: Add CommandPipeline.raw_out for retreival of the raw stdout bytes
push time in 3 days
issue commentxonsh/xonsh
Strip away newlines in subcommand output `$(...)`
I do like to keep an open mind, though! So I can be convinced away from the above opinions.
Good to hear! I was fearing this is a dead end.
- I agree with @anki-code that
@$()should remain as-is since it's very xonsh-specific in nature and the ability to spread arguments is pretty cool - I think the other subprocess operators shouldn't change as well, since if we're using them we're probably doing something more advanced than just command substitution.
The basic jist is that $() is used daily for command substitution, and keeping the trailing newlines isn't robust enough for day to day use (e.g. when dealing with paths you have to use @$() which is cumbersome and won't work for paths with spaces).
If we're using $() in more complex python code, we probably want to be accurate, and the command line(s) will probably be bigger such that adding a .rsplit() is more legitimate
comment created time in 3 days
PR opened xonsh/xonsh
<!--- Thanks for opening a PR on xonsh! Please include a news entry with your PR to help keep our changelog up to date! There are instructions available here: https://xon.sh/devguide.html#changelog -->
<!--- If there is specific issue / feature request that this PR is addressing,
please link to the corresponding issue by using the #issuenumber syntax.
Thanks again! -->
This PR allows using a command's binary output as a python object.
For example:
x = !(head -c 100 /bin/python3).raw_out
pr created time in 3 days
push eventdaniel-shimon/xonsh
commit sha 27e71605653f656c8200572acdaaae65395adfaa
procs: Add CommandPipeline.raw_out for retreival of the raw stdout bytes
push time in 3 days
push eventdaniel-shimon/xonsh
commit sha c93e60c2919d3e0ab56982cfbf571d35ede62e43
procs: Add CommandPipeline.raw_out for retreival of the raw stdout bytes
push time in 3 days
push eventdaniel-shimon/xonsh
commit sha d8390cf9f1d06fce6f4f87ecc339b152bd86b25b
procs: Add CommandPipeline.raw_out for retreival of the raw stdout bytes
push time in 3 days
push eventdaniel-shimon/xonsh
commit sha 2277ffad112a0e8d731d1289e94e10a99f4bc44d
procs: Add CommandPipeline.raw_out for retreival of the raw stdout bytes
push time in 3 days
issue commentxonsh/xonsh
Strip away newlines in subcommand output `$(...)`
I understand what you're saying but it still doesn't feel very helpful. I'm talking of course only about subcommands which are substituted inside another command, in which case I can't really see how that's helpful.
In any case I guess this issue is a pretty opinionated thing if it has been discussed so many times. Do you think adding a config option like $XONSH_STRIP_SUBPROC would be exceptible?
comment created time in 3 days
issue openedxonsh/xonsh
Strip away newlines in subcommand output `$(...)`
<!--- Provide a general summary of the issue in the Title above --> <!--- If you have a question along the lines of "How do I do this Bash command in xonsh" please first look over the Bash to Xonsh translation guide: https://xon.sh/bash_to_xsh.html If you don't find an answer there, please do open an issue! -->
Expected Behavior
<!--- Tell us what should happen -->
Subcommands ($(...)) strip trailing newlines like other shells (bash, zsh, fish).
Current Behavior
<!--- Tell us what happens instead of the expected behavior -->
<!--- If part of your bug report is a traceback, please first enter debug mode before triggering the error
To enter debug mode, set the environment variable XONSH_DEBUG=1 before starting xonsh.
On Linux and OSX, an easy way to to do this is to run env XONSH_DEBUG=1 xonsh -->
For example (how I stumbled upon this issue), the command
git diff $(git merge-base master some-branch) HEAD
won't work because the newline isn't stripped from the subcommand.
Proposal and Reasoning
Run .rstrip('\n') on the subcommand output.
This relates to #2304, and the following is my rational:
All unix and windows cli commands append newlines to their output, and when $(...) is used in all shells adding a newline isn't appropriate or needed.
@$(...) isn't the solution either, since users don't always want to split the output to different arguments.
For example, ls @$(some_command) will fail if there's a space in the output.
Here's another example.
On windows, currently there's no easy robust way to do the following:
diff $(where xonsh) some_xonsh won't work because of the newline.
diff @$(where xonsh) some_xonsh isn't robust since xonsh's path might contain a space.
If a user wants to access the entire output without stripping, they can use the more complete !(...) feature.
For community
⬇️ Please click the 👍 reaction instead of leaving a +1 or 👍 comment
created time in 3 days
issue commentxonsh/xonsh
trailing newline characters from __iter__ method of !() captured output
Hi, this is an issue I stumble upon all the time, and I resort to doing things like @($(cat SOME_FILE).strip())
The thing is that unix and windows cli commands always append newlines to their output, and when $(...) is used in all shells adding a newline isn't appropriate or needed.
@$(...) isn't the solution either, since users don't always want to split the output to different arguments.
For example, ls @$(some_command) will fail if there's a space in the output.
Here's another example.
On windows, currently there's no easy robust way to do the following:
diff $(where xonsh) some_xonsh won't work because of the newline.
diff @$(where xonsh) some_xonsh isn't robust since xonsh's path might contain a space.
I'm suggesting that $(...) will run .rstrip('\n') on it's output.
If a user wants to access the entire output without stripping, they can use the more complete !(...) feature.
comment created time in 3 days
Pull request review commentxonsh/xonsh
Create ExecAlias for aliases that contain IO operators
def test_subprocess_logical_operators(xonsh_execer, xonsh_builtins, alias): ales = make_aliases() ales["echocat"] = alias assert isinstance(ales["echocat"], ExecAlias)++[email protected](+ "alias",+ [+ "echo 'hi' | grep h",+ "echo 'hi' > file",+ "cat < file",+ "COMMAND1 e>o < input.txt | COMMAND2 > output.txt e>> errors.txt",+ ],+)
Done
comment created time in 3 days
push eventdaniel-shimon/xonsh
commit sha cf87c2fdc8904a7382d9f357079cc8a488b75ace
aliases: Create ExecAlias for aliases that contain IO operators
push time in 3 days
pull request commentxonsh/xonsh
Create ExecAlias for aliases that contain IO operators
Hi guys, it's all good, I've forgotten about this PR myself 😁
@laloch - if I understand correctly, ExecAlias behaves like normal xonsh (which would also work for simple commands without IO redirections), while creating a list alias is an optimization. So how can it be dangerous to create an ExecAlias instead of a list alias?
comment created time in 8 days
issue commentdaniel-shimon/rpp
Hi, haven't been here for a while 😅 Could you try compiling on master now according to the new compilation instructions (using cmake)?
comment created time in 9 days
push eventdaniel-shimon/rpp
commit sha faffc4cc986d0e4e1c46ed50c0ab71f0a397e1e0
readme: Update compilation instructions to use cmake
commit sha 50f29ca301ddd17eae1cbd04087d61e6033cbd6b
readme: Add build status badge
push time in 9 days
pull request commentdaniel-shimon/rpp
Also, I've made some changes to master, so please rebase :)
comment created time in 9 days
push eventdaniel-shimon/rpp
commit sha eb6cda5c63644c74f64ab71d8915edd4b54e815e
tests: Remove custom dockerfile
commit sha b7788c5c04b2afed41978f9479b2e80326a76886
tests: Ensure tests don't chdir
commit sha 7be2c51b56b37e804aa5a176f92af1df5e958632
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha 62079cf03d990bde82e8cbc6abdd84cf9c3a868e
tests: Remove custom dockerfile
commit sha 0ea4c999fa3111930c17549c55821bfe84c39860
tests: Ensure tests don't chdir
commit sha 4cd76adcbe89217aae9644b3fa55ec72a3a38a6c
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha 9c81f9312736ff570c71deeafb80a341e7b390f9
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha 2c35a546b16fef577a09330eed48877ff2b40f1d
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha 9bec3eda7b92ca07a89e1b1861fe1fdf99008250
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha 23334338214ea60a8919069f6ae91d0c6ddc1108
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha 72421855fbcf00e57af134ff18146dc1fa556bfa
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha 8aaf1aeee651059fdea77c8298e6f4a398f1d2fe
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha 1f907b504616efafbc033a52274f4a8403a2f3f4
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha 9d7cfda7cb03fe742cf33649c9c4ac46415c1f6d
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha e0bf6dabf55352620abb1fa38984660b224b4daf
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha 3e07fd506dbed00b9a326dd3020a95f14c8fbd65
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha 6d151d245917400a2f166e13a68a1c423197bfd5
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha f1ae09a296a34b5556f104d7511d6a3e31657f3d
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha e97186f7ec5b601a2a7af70ce8de3411273b602b
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha 89a42dea83316f021fe2758284a24f972302a15f
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha 82ef34ca6a87b0700f16ece772f520c96aa1363c
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha 0fbc68062ce79182c8073a160d849148c594f562
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha 00b247d03604275ce337033cc3ec77e56058c79c
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha 5558ead68b9d43ef786646fa863fe77239db2150
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha 46cc65f361cec7de601068d834ecf90d77c4aa28
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha 70542743c17532c7f18548246293964abb1f59c9
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha 93e0cf6690ae7d5b5651b7432b56b3c433166ad2
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha 88336ac6ed23acaf84a56aa63233e9f44e075521
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha d747c3e5b6a067bdaeffff6fdc9d4b2311defd55
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha 70e80bace115fc1ebd00848e9d47ade4e8dde582
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha d500390c3a1dd67801723484e07eff034ecacdcc
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha 0ffeee0874680a4b40a451866b18000cb3abd8c8
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha 21304803fa6947918424bc8cdf7812c32a6cbecb
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha bb6d49879c915596439bfb01ec9953d33c46f14d
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha 88694f5380697509000a4b7aea53c848c5e1c1b2
ci: Compile and test rpp in github ci
push time in 9 days
push eventdaniel-shimon/rpp
commit sha c8ea2cf6f4405f496514ba4f784b5ad405c7fb66
ci: Compile and test rpp in github ci
push time in 9 days
startedRikorose/gcc-cmake
started time in 9 days
push eventdaniel-shimon/rpp
commit sha 7e4283cc2786d38c3a7b04fcfd511f7e78ddb60b
io: unix: Ensure io errors are checked everywhere
push time in 9 days
issue commentdaniel-shimon/rpp
Ok הדפס is pretty good :) You're welcome to make a PR 🔥
comment created time in 12 days
startedjdidion/autoclick
started time in 2 months
push eventdaniel-shimon/xonsh
commit sha fb04d8265777bf91a03e1bf979b9c7195d9d6ac9
aliases: Create ExecAlias for aliases that contain IO operators
push time in 3 months
PR opened xonsh/xonsh
<!--- Thanks for opening a PR on xonsh! Please include a news entry with your PR to help keep our changelog up to date! There are instructions available here: https://xon.sh/devguide.html#changelog -->
<!--- If there is specific issue / feature request that this PR is addressing,
please link to the corresponding issue by using the #issuenumber syntax.
Thanks again! -->
Currently after setting
aliases['test'] = 'ls | wc'
Running test will result in ls | wc being printed to the screen.
The reason is Aliases.__setitem__ parses this into a list instead of into an ExecAlias object.
The fix is to add the IO operators (>, <, and |) to the regex that decides whether to create an ExecAlias or not.
pr created time in 3 months
push eventdaniel-shimon/xonsh
commit sha 763d241c68ab8004d3cd9a065ce44eaf5fd98e4b
aliases: Create ExecAlias for aliases that contain IO operators
push time in 3 months
create barnchdaniel-shimon/xonsh
branch : exec-aliases-on-io-operators
created branch time in 3 months
push eventdaniel-shimon/xonsh
commit sha 8a021b37275859c3fd73a47bc5eb49a3c9b842f5
Set argv[0] of a subprocess to the command as inserted by the user Currently Xonsh passes a resolved path of an executable as argv[0] argument. This changes the argv[0] to containd the command as inserted by the user. The new behavior is consistent with bash and other shells. Some programs behave differently in dependence of the argv[0] value. See #3617 for details.
commit sha 861bf4061567e788ad5f84eff2be8ccd6b75d1d1
changelog entry
commit sha fc2fc776a2e263bdf01e2f66eebe3a0c4df44432
Don't clear JSON history buffer while it's being flushed
commit sha 9629568c1b4ef232c253260fdb581f36525d0211
JSONHistory: Fix possible indexing error Due to $HISTCONTROL setting some history entries may not be always flushed to the file and the on-disk history may actually be shorter than it was in the in-memory buffer. This patch fixes the indexing error occuring under such condition.
commit sha 6e9d1063b587857832ddef36bad311a88451f9a7
News entry
commit sha dfcce2b4d010c3e202624a9255cf96d793a457bd
Add test for subprocess argv[0] The test needs access to procfs, so it only runs on Linux.
commit sha 784c5286ef93e85613b4a7d609297ea71d49c624
Remove most of Python 3.5 compatibility code. (#3654) There now should not be any remaining 3,5 conditinal code. We now directly use inspect's getouterframes, so remove it from inspector The 3.5 parser get merged into 3.6 and a number of global vaiable referring to 3.5/3.6 are now gone. The only remaining mention is appveyor test, which are anyway failing but not being seen as so by GitHub, so I'll leave them alone.
commit sha a8d4a57f01a25b1ce77f0a3adec1c0b11f49ad1a
Environment variable registration, deregistration (addresses #3227) (#3377) * First attempt at register/deregister machinery for envvars * Added detailed docstring, simplified ensurers Also added some type checking that became clear from docstring writing. * Changes in response to @scopatz review Simplified kwarg names. * defaultval -> default * Created new Var namedtuple, as well as DEFAULT_VARS We should now delete DEFAULT_ENSURERS, DEFAULT_VALUES, DEFAULT_DOCS, and refactor Env to use the new single namedtuple and the DEFAULT_VARS dict * Removed DEFAULT_ENSURERS, DEFAULT_VALUES, DEFAULT_DOCS Now need to edit Env to use new DEFAULT_VARS, Var namedtuple * Finished updating Env object to use new combined Var Also made corresponding changes elsewhere ensurer was used * Working on test failures * More fixes in light of test failures * Set default values for Var in register. There's a bit of duplication here, but makes for a cleaner function. * Black reformatting on environ.py * Removed history replay * Added register tests * Added addtional deregistration test * Removed all replay references, in docs too * Added news item for env-reg-dereg * trigger rebuild * doc fix * more doc fixes * again * attr names * reorder imports * fix flake error Co-authored-by: Anthony Scopatz <[email protected]>
commit sha d41e6ddf72377ecfc6b175370882e8561544a2c2
Call repr() when pretty() fails in _pprint_displayhook
commit sha 9ca090679351045c1989b347503c1a17e6ec6473
Merge pull request #3563 from xonsh/fix-json-history Fix json history
commit sha c40c9de9ad49807e2843af2024045fa8c580e56e
Merge pull request #3627 from laloch/argv0 Set argv[0] of a subprocess to the command as inserted by the user
commit sha 8f131a089c9144eb961bd0eda22fadf31ac787ed
Merge pull request #3656 from daniel-shimon/print-mocks-correctly Call repr() when pretty() fails in _pprint_displayhook
commit sha f6afc4d16fa92ca750a89f8030b973226efaa1f1
Add vended prompt_toolkit version 3.0.5
commit sha df55eab0b40aaf0d5cd6e875050c1cb35eb4df65
Exclude veded ptk from black and flake8 checks
commit sha 6dcf619c0160cbfdf95664d93f8b856f24e1d0d7
Add vended ptk to pakages setup.py
commit sha 743f8f2c0ff81a6d6e008a801e8ffb4199d46eff
prompt_toolkit is the best
commit sha bdd678fea2df95ee999141a0b2e567b9592b7a41
vend prompt_toolkit if not available or too old
commit sha 586e7b248bf911edf367d6dca79089f8dd689ae4
fix regression with LC_MESSAGES missing in locale
commit sha 34c6549b1374701c2acf13871b48bd5cbb211642
Add news entry
commit sha ffdb999a2e67d6a82691c7dbe1f5d0df4478c715
fix regression with LC_MESSAGES missing in locale
push time in 3 months
issue commentxonsh/xonsh
standard locations for aliases, abbrevs... and CLIs to update them imperatively
I agree.. Maybe source-foreign can save the resulting aliases etc. in those files too
comment created time in 3 months
issue commentxonsh/xonsh
Neovim when called through $EDITOR is broken
Can confirm on WSL2
comment created time in 3 months
pull request commentxonsh/xonsh
Add Python 3.8 assignment expressions ("walrus"/PEP 572)
Nice!
I wanted to do this myself but didn't really have the time
How about making the changes to xonsh/parsers/base.py in xonsh/parsers/v38.py instead? For instance:
def p_test_or_star_expr(self, p):
"""test_or_star_expr : test
"""test_or_star_expr : namedexpr_test
| star_expr
"""
super().p_test_or_star_expr(p)
For all the functions you're changing
comment created time in 3 months
Pull request review commentxonsh/xonsh
Call repr() when pretty() fails in _pprint_displayhook
def _pprint_displayhook(value): builtins._ = value return env = builtins.__xonsh__.env+ printed_val = None if env.get("PRETTY_PRINT_RESULTS"): printed_val = pretty(value)- else:+ if not isinstance(printed_val, str):
But that's the point - when this issue happens, pretty(value) returns value.xonsh_display() which is itself a mock object.
So the way to make sure pretty succeeded is to check if it returned a str like it should.
comment created time in 3 months
issue closedxonsh/xonsh
Do we really support python3.5?
According to the docs xonsh supports python3.5, but it doesn't seem to actually support it:
- There are f-strings in a lot of places
- The CI only runs with python3.6 and above
- Black only runs with python3.6+
Shouldn't the docs and setup.py change to python3.6+?
closed time in 3 months
daniel-shimon
issue commentxonsh/xonsh
Do we really support python3.5?
Awesome! Thanks!
comment created time in 3 months
push eventdaniel-shimon/xonsh
commit sha d41e6ddf72377ecfc6b175370882e8561544a2c2
Call repr() when pretty() fails in _pprint_displayhook
push time in 3 months
PR opened xonsh/xonsh
When evaluating mock objects, pretty returns the object's .xonsh_display attr which is itself a mock, and this fails later on:
We can handle it by calling repr() when it fails.
pr created time in 3 months
push eventdaniel-shimon/xonsh
commit sha 60fecdf2424f100241abc84dbaf98c885307d5b6
Fix error message The error message for `vox rm` wrongly assumed that `vox deactivate` needs an argument. Example of the error in action: ``` (jnov) fermigier@mbp-stefane-abilian ~/projects/jnov master $ vox rm jnov The "jnov" environment is currently active. In order to remove it, deactivate it first with "vox deactivate jnov". (jnov) fermigier@mbp-stefane-abilian ~/projects/jnov master $ vox deactivate jnov usage: vox [-h] {new,create,activate,workon,enter,deactivate,exit,list,ls,remove,rm,delete,del,help} ... vox: error: unrecognized arguments: jnov (jnov) fermigier@mbp-stefane-abilian ~/projects/jnov master $ vox deactivate Deactivated "jnov". ```
commit sha 0fb003c4db4b5b119c82fd6d715c4bb0226dcf2f
Please click the 👍 reaction
commit sha 37c1828bfc33fc364225802989f07e173e9b23ae
bash2xsh improvements
commit sha 8a2ff1f1aae7ee4e494d0b38bfd274bedab503b5
news
commit sha bcffe825df2babdca7633347d01926e71423e3ff
Add xontrib-pdb. Runs pdb on SIGUSR1.
commit sha e5692e9b68a665f3537964b512363d3fcf4effbe
Changelog entry
commit sha bd8b5f548ddc1d829c4413f9ef8ce00659140aaa
#3402 set the exit code for single commands
commit sha 76cd2f543f8cdfed05a899dff573c7fc620aa0ec
Merge branch 'master' into issue_3402
commit sha 46143f2b6ecd147f44520100d16cfd177f85e501
Integration tests for single command return codes #3402
commit sha b64d3b969d76eae4b8f571337e19b25b226ca2d1
Fix ctx-free parser stripping the trailing newline
commit sha 7bec47bd197f53d96c4b00702cf96bd2ef1c7dfc
changelog entry
commit sha 3d954cacaeb246b66fee04beaee542f8e020b8c0
tests: Fix line continuations test
commit sha 1ad143f9a546a905a8f0b83421de07fce36fb0dd
Fix TypeError triggered by unexpected return from callable alias
commit sha 5ff57aee7f3d4940e7c8c7acaad253ddbc41031e
changelog entry
commit sha 9c0ac6e406b89da8a52216c4d9858ca7987a6d7a
News entry for single command exit code fix (#3402)
commit sha cf9bc3c82eb4110c1b12f7d3d92037667cd7c772
News entry rst fix (#3402)
commit sha a1a08386bcaf2900761d15c671b136c6d9abca6a
Single command return code integration tests fixed for macOS (#3402)
commit sha f67c6e83ec676bd1a68ca12865b8d0a19d75033d
Remove distutils fallback. Fixes #3638. Also remove Python 2 compatibility imports.
commit sha c63e1665a7a4589863772ea13c8b0ea790415e89
Add changelog entry
commit sha ad3351462bed5245fe64af699bc961f613061749
Declare build-time dependency
push time in 3 months
pull request commentxonsh/xonsh
Remove some of Python 3.5 compat.
BTW @carreau, can you squash these commits together with the first one's message? They're all basically Remove some of Python 3.5 compat.
comment created time in 3 months