Re: [Fab-user] OS X and fabric.contrib.files.exists

[Tom Evans]

On Mon, 2009-06-01 at 19:02 -0400, Jeff Forcier wrote:
> 2009/6/1 Niklas Lindström <address@hidden>:
> > Hi again,
> >
> > I just noticed that `fabric.contrib.files.exists` doesn't work on OS
> > X, due to the "--color" flag. Is that a necessary precaution for some
> > systems, or could it be removed altogether?
> 
> A number of things in the contrib.* files are unlikely to be fully
> portable right now, unfortunately, since they're still largely based
> on stuff I wrote for my own environment.
> 
> I'd like to make them moreso (I'd also like to put in ANSI color
> stripping so passing --color=never isn't necessary) but for now, if I
> take that flag out it won't work for me or anyone else with color 'ls'
> enabled on the remote end, so it becomes a "who to inconvenience" game
> with color 'ls' folks vs non-GNU-ls ones :)

This should be taken care of by the environment of the remote user, to
*not* have things like colour ls enabled. That is why we have .bashrc
and .bash_profile, for the differences between interactive and non
interactive. 

> 
> We could put in a stopgap solution which checks system type and omits
> the --color if it doesn't appear to be Linux, e.g. "if run('uname -s')
> != 'Linux'". I've done this in my dotfiles for similar reasons, with
> some success.
> 
> -Jeff
> 

Whilst we're on linuxisms, there are a couple of others. I don't know if
it is useful to bring them up? Anyways,

1) Hard coded path to bash. Only on linux does bash get installed
in /bin/bash.
2) Assumption of existence of bash. Most boxes I use never have bash
installed. It would be better to respect $SHELL.

I appreciate how hard it is to support an environment that you don't
actually use. I'll try to make some patches to better support our
servers (FreeBSD).

Cheers

Tom