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 <[email protected]> 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
