Consider shell env var support #263
Comments
Matthew Swasey (mig) posted: Regarding making sure variables are available to all commands in the pipeline, you could use export or even set automatic exporting, e.g.:
would turn into:
or:
Both these forms are POSIX compliant IIRC (they work in sh, bash, dash, ksh at least) but may not work in all shells (e.g. csh). on 2010-12-02 at 05:13am EST |
Jeff Forcier (bitprophet) posted: Hah, I had totally forgotten that that's a valid way of doing this, but you're quite right. That would likely simplify the implementation a bit too -- should make it just another special-case of prefix (albeit one where it must always be placed at the beginning of the commands list). Using a Fab env-var dict and on 2010-12-08 at 01:16pm EST |
#438 is a pull request implementing at least part of this functionality. |
Description
Right now it's possible to append prefixed additional commands to a block of run/sudo statements with
prefix()
(and special cases likecd()
), i.e.something_refactored && individual_commands_go_here
-- but what still requires manual string manipulation is environment variables, i.e.SOMETHING=refactored individual_commands_go_here
.Naive implementation would simply ape
prefix()
, be a single context manager, and add env vars to the individual commands run inside the block, so e.g.would execute:
However, this naive approach would fall down when combined with
prefix()
, because this:would turn into this:
and NOT this, which some users might need/expect:
And because we can't have nice persistent multi-command shell environments, using e.g.
export
is out of the question.That said, it should definitely be possible to reference the data stored up by
shell_env()
when executingprefix()
-- doing so would just be a slightly more complicated implementation, and it's possible some users might not want the shell env vars applied to theirprefix()
commands. (Though I'd argue the common case would be the one where we apply the env vars to both prefixes and final commands.)Finally, make sure
sudo()
is appropriately handled, though looking at our current method of building up command strings, I don't think we'd need to do anything special.Note that I'm using
shell_env()
as a placeholder name here, though it's not a bad name and avoids the pitfalls of A) confusing people w/r/t Fabric's env var versus shell env vars, and B) you can't just usevars()
as that's a Python builtin.That said, name suggestions are welcome.
Originally submitted by Jeff Forcier (bitprophet) on 2010-12-01 at 03:11pm EST
The text was updated successfully, but these errors were encountered: