Sure, using find or which, etc., can be used to locate a particular app, but that's not really the point. Why not simplify things and put all binaries under /usr/bin? Then you don't have to teach users about silly distinctions like "Oh, see, if it's an app that's meant to be used by a System Adminstrator, then it goes into /usr/sbin". Who cares? Just put everything in /usr/bin to keep things simple.
On Mon, Dec 5, 2011 at 4:24 AM, Dane Mutters <dmutt...@gmail.com> wrote: > I don't know if the original poster has since learned this, but I think > it's worth noting several things, in case the person coming over from > Windows hasn't figured it out. (If this is a non-issue, please disregard > this email.) > > 1) Linux/Unix executables don't have a .exe extension. Typically, they > don't have any extension at all, and can conceivably have every extension > imaginable (including common ones like .sh for scripts). If you're looking > for an executable, forget looking for its extension. Try using the "find" > command to look for executable files, or if you know the one you want, > already, use the "which" command, as above. > > 2) You almost certainly don't need to find that file. As mentioned above, > if it's not in your PATH setting, then something is broken. This is pretty > rare. If you need to execute a command--from a terminal or from an "open > with" dialogue, just type the command (in the appropriate dialogue box, as > needed). If you want to open a PDF, and the GUI hasn't figured out how to > do that, type "acroread", "evince", or whatever you have installed into the > box. > > 3) <rant> +1 about Windows having an absurdly hard-to-use filesystem, > where finding binaries/executables is concerned. Once you learn Linux, > you'll bless its build-in filesystem, and probably find little/no need to > mess with it. For that matter, +1 to all the stuff about /bin, /sbin, > /usr/local/bin, /usr/local/sbin, /opt, etc. having useful, specific > purposes. Sure, it bugs me when some program insists on installing > someplace I don't think makes sense. Usually it'll let me change it upon > install, if it's from a script, but if not, I can still put it into the > PATH if it's not already there, and after that it doesn't matter! So long > as the uninstall functionality works for a given program (which it REALLY, > REALLY should...), and the executable structure of the program is remotely > sensible (looking at you, OpenOffice, Mozilla, etc.), it's all gravy, so > far as I'm concerned. Proprietary programs are the more problematic > culprits, anyway, and there's not much a distribution can do about them, so > far as I'm aware. </rant> > > 4) I've never liked Fedora, anyway. :-p > > > I'm sure the real gurus here know a lot more about the specifics than I > do, so have at it! > > --Dane > > > On Mon, Nov 7, 2011 at 3:16 AM, Colin Watson <cjwat...@ubuntu.com> wrote: > >> On Sat, Nov 05, 2011 at 02:40:31AM +0800, John McCabe-Dansted wrote: >> > We could even enhance which to look in obvious places off the path >> (perhaps >> > locatedb?) and print the output on stderr if we really wanted to. >> >> Please don't - 'which' is used in scripts and needs to preserve its >> current behaviour. Any extra behaviour should be added to a >> different/new program. >> >> -- >> Colin Watson [cjwat...@ubuntu.com] >> >> -- >> Ubuntu-devel-discuss mailing list >> Ubuntu-devel-discuss@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss >> > > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > >
-- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
