fabric.contrib.files.sed uses "non-standard" flag '-r' #84

bitprophet opened this Issue Aug 19, 2011 · 8 comments


None yet

2 participants



For example, using OS X it's -E and thus all contrib.files commands that depend on sed fail.

Not sure if there are any good solutions to this problem. Perhaps using a named argument such as "sed_extended_regexps_flag='-r'"?

Originally submitted by Jonas Nockert (lemonad) on 2009-11-08 at 06:43am EST

@bitprophet bitprophet was assigned Aug 19, 2011

Jeff Forcier (bitprophet) posted:

This is kind of a generic issue affecting a LOT of stuff, especially contrib which is currently "approaches that work for Jeff on two different Linux distros and that's about it."

There's two possibly-good solutions I can see offhand:

  1. Improved system-type detection, which I do have plans for. I have a large system-oriented "fabfile" package from which I will continue expanding contrib, which currently detects RedHat vs Ubuntu vs Debian, and that could definitely use expansion into something useful for this purpose.

  2. Your argument idea, though I think it would be a good candidate for a global option. Right now, stuff like use_sudo has to be preserved through call chains, and arguments to lower level stuff like sed would similarly need a lot of percolating.

    I'd like to try moving from that to more env (or similar) options, so one
    could do something like this:

    with settings(use_sudo=True, sed_eregex_flag='-r'):
        comment('foo', 'bar')
        uncomment('biz', 'baz')

    Again, this issue could be a good candidate for trying that out.

on 2009-11-08 at 09:17am EST


Jonas Nockert (lemonad) posted:

I like the approach you've outlined better than making it a global option as it would make handling multiple systems within one fabfile possible. I generally use my macbook for development but deploy to servers running Ubuntu.

Thanks for the extensive reply! I've just being using Fabric for the last couple of weeks but like it a lot so far.

on 2009-11-08 at 09:36am EST


Jeff Forcier (bitprophet) posted:

Thanks, glad you like it :)

When I say "global option" I really just mean "env var", which could be set globally if someone wanted, but I've been trying to push folks towards using the settings context manager for locally modified behavior, as in my example.

The system detection idea, also, would naturally be flexible so that it caches the test result on a per-connection basis -- so if you ran the same task on 3 different systems in a row, it would behave differently for each if necessary. However, that's more work so I bet I'll do the env var flag option first.

Bumping down to 0.9.x now that I'm thinking of it, that particular change would be pretty quick.

on 2009-11-08 at 12:28pm EST


Jeff Forcier (bitprophet) posted:

Oh, and, I almost always reply extensively. You'll get sick of my rambling after a while, I promise ;) Now if I could just put releases out as fast as I type about them...

on 2009-11-08 at 12:29pm EST


**** (lasizoillo) posted:

In FreeBSD I have the same problem:

Bad example:

[root@] run: sed -i.bak -r -e 's/host \*/host' /usr/local/etc/munin/munin-node.conf
[root@] err: sed: illegal option -- r
[root@] err: usage: sed script [-Ealn] [-i extension] [file ...]
[root@] err:        sed [-Ealn] [-i extension] [-e script] ... [-f script_file] ... [file ...]

Good example:

[root@] run: sed -i.bak -E 's/host \*/host' /usr/local/etc/munin/munin-node.conf

Maybe change this line for this code (import it's in bad place) resolve all platforms:

import platform
if platform.system() == 'Linux':
    expr = r"sed -i%s -r -e '%ss/%s/%s/g' %s"
    expr = r"sed -i%s -E '%ss/%s/%s/g' %s"

¿What about of cygwin? ¿Works as Linux or as Unix?

on 2010-01-01 at 02:08pm EST


Is this issue likely to get movement any time soon?


This (the "tweak use of sed and friends based on target OS" idea) actually sounds like it will end up working best in the proposed "patchwork" library in #461.

Re: when it gets done, I have not specifically planned to work on this aspect of things, but I am planning on moving ahead with Patchwork overall in the near future. Depends on my day job.


Thanks to @khalas we have a temporary workaround re: detecting -r vs -E in place now.

@bitprophet bitprophet closed this Mar 19, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment