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

[Jeff Forcier]

2009/6/2 Tom Evans <address@hidden>:

> 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.

This is true, but at the same time, if we can take that burden off the
user with only a small amount of work, that's (IMO) sometimes a better
approach than simply waiting for users to run into problems and then
telling them they're doing it wrong :) even if they are.

Plus, 'ls' is only one spot where color may arise, and it may not
always be in the user's control, even if there are *usually* color
options to programs -- so ANSI stripping still feels like something
that might be a useful tool to have handy.

> 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.

Both of these can be easily changed by overriding env.shell, though
I'm definitely in favor of playing nicer with $SHELL and other env
vars, both on the local and remote ends.

If you have any suggestions for how to completely avoid having *some*
default shell defined, I'm all ears.

> 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).

Great, looking forward to it!

I hope to eventually incorporate these kinds of patches/ideas into
something more structured, as well, tying into an existing "more
robust per-host settings" idea, too (e.g. "this system looks like BSD
/ the user has explicitly told me this system is BSD, so I'll set
env.shell to /bin/sh and make sure not to use any GNU options when
constructing internal commands" and so forth.)

Best,
Jeff