Xonsh: Prefix environment variable and temporarily disable alias

[ywangd]

I noticed that following two bash usages are not covered in xonsh.

• Prefixing a command with temporary environment variables, e.g. DEBUG=1 make. I do realise that the same effect can be achieved by using environment swap(...).
• Temporarily disable an alias. For an example, if I have alias ls=ls -a, I can use \ls to temporarily ignore the alias and call to the actual ls command.

As I understand it, xonsh is not trying to replicate every Bash feature/usage. So my question is: Are above usages out of scope for xonsh? I am trying to avoid effort on something if it is not aligned with xonsh's overall direction. Thanks!

[AstraLuma]

I didn't know about swap(). More visibility on "user-facing" functions would be good.

[ywangd]

I personally think swap() is more clunky to use.

It also does not work exactly the same as prefixing env variable. But this could be an advantage because Bash's behaviour is a bit confusing.swap does inline substitution, such as the follows

with ${...}.swap(SOMEVAR='foo'):
     echo $SOMEVAR

While SOMEVAR=foo echo $SOMEVAR does not work.

[scopatz]

Hi @ywangd @astronouth7303, for what it is worth, you can use the env command instead of swap: env SOMEVAR=foo echo $SOMEVAR. swap() is really for many subprocess statements, though it can be used in a small context, too.

The guiding principle has been to not have more syntax than necessary. For the env/swap issue, env gets the job done with out additional syntax and is explicit rather than implicit. Personally, I am not opposed to adding implicit envvar setting, but I am not sure that I want to implement it myself. A PR would be welcome. Also, we'd need to decide on the semantics for how long the envvars apply. That is, do they apply for just a single command, or all commands in pipeline? My preference is the former.

As per alias disabling, we probably should have something like swap() on the aliases object. Custom syntax for this, though, is probably not a good idea. Like Bash's ability to disable history by starting a command with a space, I personally feel that it is this sort of arcana that makes Bash hard to learn, hard to use, and hard to explain. If you want to avoid an alias, it is best to be explicit about this. This can be done _either_ by using the absolute path to the executable (/bin/ls) or by using the which -s command, which avoids aliases. For example @$(which -s ls) will run ls without an alias.

I hope this helps, and we would love to have a contribution for the envvar piece if the other core devs think it is a good idea too

[WouldYouKindly]

@scopatz hi! This doesn't work for me:

$ env $SOMEVAR=foo echo $SOMEVAR
$SOMEVAR

Is there another way? Is it a bug?

[scopatz]

@WouldYouKindly - your issue is basically the same as https://github.com/xonsh/xonsh/issues/2943, this is not a bug, but rather a very difficult to implement feature. And note that the particular form that you have (<cmd> <set-env-var> <sub-cmd> <env-var>) will never work, even though we could try to make <set-env-var> <sub-cmd> <env-var> work

[gforsyth]

I'm closing this out. The pattern we use is swap. For disabling aliases, we recommend running the results of which -s <alias> to grab the non-aliased version