Hey Laurent,
I assumed that /usr/bin/cd actually did something. I did run into the
ImageMagick issue. I'm hoping graphics magick fits my needs, it
supposedly wont conflict with other software.
Thanks for the reply (& skarnet software!)
On Wed, Jul 9, 2014 at 3:06 AM, Laurent Bercot <ska-skaware_at_skarnet.org> wrote:
>
> Hi Franco,
>
>
>> What is a good practice to mitigate ambiguity between /usr/bin/cd and
>> execline's cd program?
>
>
> Honestly, it's the first time I hear of the /usr/bin/cd program.
> A quick Web search shows that it does nothing. Shells will never call
> it unless you specify the full path, since cd is a builtin; and there
> is no reason why they would want to call it. So, I wouldn't be worried
> about shadowing it.
>
> I use the slashpackage and slashcommand conventions, so my execline
> binaries are available from the /command directory, and /command is
> before /usr/bin in my PATH, so "cd" in an execline script calls
> execline's "cd". That's what I would advise to lift the ambiguity.
>
> If you're not following the slashpackage convention, however, there is
> no way to lift the ambiguity except call /bin/cd (or wherever you
> installed the execline binaries) everytime. The FHS does not provide
> a way to avoid such ambiguities, and full paths are the only failsafe
> option. (And full paths make scripts non-portable, unless you use
> slashpackage, because distributions will install binaries in different
> places. This is a sad, sad world we live in.)
>
> I really wouldn't worry about /usr/bin/cd. At worst, you can divert it
> or even remove it.
> The "import" program may be more of an issue. Apparently ImageMagick
> has a command named "import"; so I'd always use the full path to both
> commands in every case.
>
> --
> Laurent
--
franco
Received on Wed Jul 09 2014 - 21:36:10 UTC