Re: execline's cd vs /usr/bin/cd

From: Francesco Lazzarino <>
Date: Wed, 9 Jul 2014 16:36:10 -0500

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

Received on Wed Jul 09 2014 - 21:36:10 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:38:49 UTC