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

[bitprophet]

Description

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]

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

[bitprophet]

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

[bitprophet]

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

[bitprophet]

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

[bitprophet]

**** (lasizoillo) posted:

---

In FreeBSD I have the same problem:

Bad example:

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

Good example:

[root@192.168.1.20] run: sed -i.bak -E 's/host \*/host 192.168.1.20/g' /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"
else:
    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

[halcyonCorsair]

Is this issue likely to get movement any time soon?

[bitprophet]

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.

[bitprophet]

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