summaryrefslogtreecommitdiffstats
path: root/src/compose.rs
Commit message (Collapse)AuthorAgeFilesLines
* Handle STDERR, in addition to STDOUTRory Dudley2024-05-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch overhauls the reading and reciting of verses, such that the redirection of STDERR (in addition to STDOUT, which was already a feature), is now possible. Removed the 'stdout' argument from recite(), since it is no longer needed with how incantations function. A verse's couplet indicator is now a u8, instead of a bool, with certain values corresponding to types of couplets, for instance: ls | grep Ca | lolcat ^ ^ ^ | | 2: right side of a couplet | 3: both sides of a couplet 1: left side of a couplet Incantions are no longer hanlded in rune.rs, and the task macros have been removed. Now, a verse incants itself, matching on its own meter to determine how to handle the next verse. The following runes were added to help with handling STDERR: Write2 -> 2> WriteAll -> &> Addendum2 -> 2>> AddendumAll -> &>> The 'io' field in verse was changed from an Option<Rune>, to an array of Runes, since a single verse might have multiple IO operations. The following fields were added to Verse, to assist with handling STDERR: ip -> List of filenames to read into STDIN op -> List of filenames to send STDOUT to ep -> List of filenames to send STDERR to Keep track of channels when reading a poem. Channels are relating to IO operations. If channel is None, words get pushed to the verse's primary stanza (i.e. the verb or the clause). If a channel is selected, words are pushed to one of the aforementioned new fields in Verse. Read -> ip Write/Addedum -> op Write2/Addedum2 -> ep WriteAll/AddendumAll -> op and ep Notes: This commit also added tests for the new Runes.
* 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.