summaryrefslogtreecommitdiffstats
path: root/src/compose.rs
Commit message (Collapse)AuthorAgeFilesLines
* Handle aliases in read()Rory Dudley2024-04-041-1/+1
| | | | | | Instead of handling aliases in the recite() function, which requires two loops to handle properly with the current implementation, offload checking for aliases to the read() function.
* Replace env!("HOME") with env::var("HOME")Rory Dudley2024-03-301-2/+12
| | | | | | Replaced all (non-test) instances of env!("HOME") with env::var("HOME"). The env! macro should only be used in instances where the environment variable should be resolved during compile time.
* Add wrapper for global shell environmentRory Dudley2024-03-301-6/+13
| | | | | | | | Instead of having to pass around a bunch of different data structures for various shell functions, create the wrapper compose::Environment, which serves as a global shell state. It is configured via login/profile/rc scripts initially, but can of course be modified throughout the lifetime of the shell.
* Remove hard-coded PATHRory Dudley2024-03-281-0/+58
Use $PATH, instead of a hard-coded PATH from main(). This means that there is no longer a need to pass around PATH to repl()/recite()/path::refresh(), since path::refresh() can call env::var directly. Since the hard-coded paths were removed, there needs to be some way to define $PATH. When running the debug build, dwvsh will look in 'dist/etc/dwvshrc' for the initial environment setup. For the release target, dwvsh will look in '/etc/dwvshrc'. After the global rc file is sourced, dwvsh will try to source ~/.dwvshrc if it exists, so users can extend their environment without root access (assuming a release install). Notes: Throughout a lot of this program, we're calling `env!("HOME")`, in order to get the user's home directory. Technically, this is not correct. The env!() macro resolves environment variables during compile time, while env::var() gets environment variables for the running process (i.e. the shell). See https://users.rust-lang.org/t/env-vs-env-var/88119 for more info. In the near future, this will need to be addressed. Might be worth looking into what other shells do, though one idea I had was to invoke '/usr/bin/id', grab the user's ID, and use it to grab the rest of the info from /etc/passwd. This would be handled in an /etc/dwvlogin or /etc/dwvprofile most likely.