superatomic / xshe Goto Github PK

eg. IsADirectory outputs an error like {file} is a Directory and etc.

A lot more detail needs to be added to the top of README.md about the purpose and functionality of xshe.

• Simple description
• Supported shells
• Supported OSs

Add support for the Dash shell.

dash uses the same form for environment variables as bash and zsh.

Instead of having the shell expand things like $CARGO_HOME, the current environment and previous set variables should be read to get these values. This allows for setting variables in a way that works for more exotic shells which don't use the exact $VAR syntax for variable expansion.

This also requires specially handling the $(shell command) syntax and parsing it into the correct form for the given shell.

Parts

• #45
• #53
• #54

Add support for the Tcsh shell: https://www.tcsh.org/

Allow for:

echo 'PS1 = "--• "' | xshe bash

(for example)

Please verify the following:

• I have searched for existing issues that request this feature
• I have read and understand the Contributing Guidelines
• I agree to follow this project's Code of Conduct

Describe the feature that you want

In addition to being on crates.io, it would be beneficial to add xshe to other package managers. Homebrew is a package manager for MacOS and Linux. While this project doesn't meet the criteria for being added to Homebrew's main tap, we can create our own tap.

Possible implementation

A new repository superatomic/homebrew-xshe should be created. Then, users can install Xshe with Homebrew by using the following command:

brew install superatomic/xshe/xshe

In addition to creating this new repository, this repo's README.md file needs to be updated to explain the new installation method.

Additional Information

• I am able to help implement this feature myself
• I am requesting support for a new shell

Anything else?

While cargo may not be able to easily install man-pages and shell completion, Homebrew can. This means that resolving this issue will close #10.

The [once] table should be a table that only runs if it hasn't setup any of its environment variables yet. It will do this by adding a environment variable __xshe_NAME, where NAME is the name of each environment variable.

For example, to set PATH without having it keep being modified every time xshe.toml gets sourced, this can be done:

[once]
PATH = ["$BIN_HOME", "$CARGO_HOME/bin", "$PATH"]

This will set these two environment variables if there is not a environment variable named $__xshe_PATH set to 1: $PATH to the expected value, and $__xshe_PATH to 1.

Additionally, specific tables [shell.SHELL.once] (where SHELL is any of the supported shells) should be created that work like shell.SHELL but only run if the given shell is being used.

This should add the following line to Cargo.toml:

exclude = [".github"]

Add support for PowerShell (suggested by @Valente-math; thank you!).

PowerShell is different from other shells. A few notes:

• Evaling xshe's output (based on how Starship handles this):

  Invoke-Expression (&xshe powershell)

• PowerShell's documentation on environment variables.
• PowerShell's documentation on quoting rules.

Additionally, adding support for PowerShell means being more serious about supporting Windows. While precompiled executables of xshe for Windows have been available for a while now, there has been no testing for Windows compatibility. The biggest concerns are whether get_file_path_default() will work correctly on Windows, and whether the XDG config directory (default: ~/.config) is the correct default location for xshe.toml on Windows machines. As PowerShell is cross-platform, this is not directly relevant to this issue, but still very important to look into.

More information should be outputted when needed. The crate clap_verbosity_flag can be used for this purpose.

As outlined by the crate, this would add the following features:

• -q silences output
• -v show warnings
• -vv show info
• -vvv show debug
• -vvvv show trace

Add support for the Elvish shell: https://elv.sh/

It looks like setting environment variables takes the form of:

set E:NAME = VALUE

Where NAME and VALUE are substituted. Note that we do not use double quotes here– Elvish will not word split and will also not expand variables inside of quotes.

The autocompletion which was added in #50 is not the most optimal and does not perfectly reflect the actual accepted arguments and options that xshe accepts.

This issue may be resolved in two ways:

• Writing dedicated autocompletion scripts for each shell instead of generating them with clap_complete
• Improve clap_complete to better reflect the actual expected arguments

Part of #38.
We need to specially handle the $(shell command) syntax.

Details:

• It must translate into the correct form for the given shell. This is easy for Bash, Dash, and Zsh, a bit more complex for Fish, and more challenging for other shells. While we only currently have support for bash, zsh, and fish, we need to make a system that can work for any shell.
• It must allow for escaping the ) character to be able to use them inside of the expression.
• You must able be able to escape the $ to not expand it. This is also relevant to #53.

Currently, the shell option introduced in version v0.2.0 is required, meaning that all files that don't have [shell] somewhere in the file are classified as invalid.

Fix: make the value of Cli.shell an Option.

Add support for the Xonsh shell: https://xon.sh/

Setting environment variables are done like this, but expanding $VARS in string literals might be a challenge. Custom shell-agnostic syntax might have to be implemented.

Please verify the following:

• I have searched for existing issues that resolve this bug
• I have read and understand the Contributing Guidelines
• I agree to follow this project's Code of Conduct

Xshe Version

0.4.2

Crash Report

report-a9af31f5-2feb-46b7-857d-2f345bb40f57.toml.zip

Steps To Reproduce

The easiest way to demonstrate this bug is to pass the xshe binary into itself:

cat $(which xshe) | xshe bash -p

This outputs the following:

Well, this is embarrassing.

xshe had a problem and crashed. To help us diagnose the problem you can send us a crash report.

We have generated a report file at "/var/folders/by/4gzq5k5s1wd5rhj5k7vgrk8r0000gr/T/report-a9af31f5-2feb-46b7-857d-2f345bb40f57.toml". Submit an issue or email with the subject of "xshe Crash Report" and include the report as an attachment.

- Homepage: https://github.com/superatomic/xshe/

We take privacy seriously, and do not perform any automated error collection. In order to improve the software, we rely on people to submit reports.

Thank you kindly!

Which operating systems are affected?

• macOS
• Windows
• Linux

Which shells does this affect?

• Bash
• Zsh
• Fish

Anything else?

This is caused by the .unwrap() call in read_stdin():

It needs to be matched against, and a nice, informative error should be displayed instead panicking.

This is a general issue. Do not close this until all code that should be tested is fully tested.

Over the releases leading up to version 1.0.0, test cases should be added. The end goal is to have tests for 100% of all cases.

New pull requests that introduce features should also introduce tests for those features. Code that has already been added should have separate tests added specifically for them.

Tracking:

• #65
• #63

Due to the way that shell variables are expanded in #98, an entire variable declaration can result in a blank value if any of the variable expansions that are a part of the statement have not been defined yet. It would be better to simply have the variable itself resolve to nothing instead of the entire statement, or for an helpful error to be displayed to the end user.

How to Reproduce

eval "$(xshe bash -t '
UNDEFINED_VARIABLE = false # just in case
VALUE = "something important followed by an $UNDEFINED_VARIABLE"
')"; echo $VALUE

Actual Output

Expected Output

something important followed by an 

This is a bug with the implementation of #45. Specifically, the problem is here:

On line 236, the array of values is converted into a string. The problem is that this happens before tildes are expanded, so when line 251 executes, it only expands the first tilde, if it exists.

Each array item should be expanded separately. This is probably a good time to move the logic for escaping regular expressions into it's own function along with tilde explanation and the future expansions #53 and #54.

Things to do:

• Add arg_required_else_help
• #49
• #50

The environment variable $XSHE_FILE should be able to set where xshe checks for its configuration file if none of the flags -p, -t, or -f are set.

Right now, the program checks locations in this order:

• $XDG_CONFIG_HOME/xshe.toml, if $XDG_CONFIG_HOME is set.
• ~/.config/xshe.toml.

The desired behavior is add the following check before the other 2:

• $XSHE_FILE, if $XSHE_FILE is set.

eg. xshe fish --toml 'EDITOR = "$(which micro)"' --> set -gx EDITOR "$(which micro)"

The README.md lists a lot of important information, but it's getting pretty long. It would be better to split up the README into multiple sections and have an actual documentation page.

We will be using Docsify for rendering the static documentation as a website, and hosting with GitHub pages. This also gives the project a website.

While we could use GitHub's Wiki feature and render the documentation from there, I believe that it's better to keep the documentation in the same location as the code so that it can update alongside of the code. As such, we will put the documentation in a /docs directory in the project root.

Currently, all shells are given the exact same environment variables. While this is optimal for most variables, it is sometimes useful to have different variables be set for certain shells, or to have different shells have different values.

Each shell's specific variables should be represented as a TOML table in a new table shell, with a name corresponding to the shell (eg. [shell.fish]).

Specific shell options should always come after the options that apply to all shells.

Example

EDITOR = "$(which nano)"
CARGO_HOME = "$XDG_DATA_HOME/cargo"

[shell.bash]
HISTFILE = "$XDG_STATE_HOME/bash_history"

[shell.zsh]
HISTFILE = "$XDG_STATE_HOME/zsh_history"
ZSH_CACHE_DIR = "$XDG_CACHE_HOME/oh-my-zsh"

Currently, the README.md file explains how to use the project, but it can be improved. This is a general issue, but some things to improve would be adding more detail to the installation process and specifying more options and use cases.

Currently, to declare shell specific variables (#4, implemented in #7), this syntax is used:

[shell.bash]
HISTFILE = "$HOME/.bash_history"

or this:

shell.bash.HISTFILE = "$HOME/.bash_history"

This has a couple of problems:

• Writing this syntax out on one line like shell.SHELL.VAR is verbose.
• While it's a minor problem, it is impossible to set a variable named shell.
• All shell specific variables are set last, not in the order in which they appear in the file.

To fix this problem, this new syntax will be implemented that looks like this:

HISTFILE.bash = "~/.bash_history"

Up until the v1.0.0 release, the old syntax will still be usable, but will emit warnings.

Please verify the following:

• I have searched for existing issues that resolve this bug
• I have read and understand the Contributing Guidelines
• I agree to follow this project's Code of Conduct

Xshe Version

0.5.1

Current Behavior

Passing arrays in fish shell with xshe defaults to treating them as a path series due to the automatic addition of the --path argument.

Expected Behavior

The shell script should be able to differentiate between an array intended as a series of paths and a regular array. Users should be able to pass a regular array without the script automatically considering it as a path series.

Steps To Reproduce

1. Use xshe to set an environment variable as an array in the fish shell.
2. Observe that the array is treated as a path series rather than a simple array.

❯ echo "XDG_DATA_DIRS   = ['element_1', 'element_2']" | xshe --pipe fish
set -gx --path XDG_DATA_DIRS 'element_1':'element_1'

Which operating systems are affected?

• macOS
• Windows
• Linux

Which shells does this affect?

• Bash
• Zsh
• Fish

Anything else?

No response

Sometimes, all that matters is that a variable is set, and it doesn't matter what it is set to. In this can, this syntax can be used:

HOMEBREW_NO_ANALYTICS = true

This sets the HOMEBREW_NO_ANALYTICS to 1.

And to unset variables that are set, a variable can be set to false.