On Sat, Nov 09, 2002 at 08:33:51PM +0000, Mikhael Goikhman wrote: > On 09 Nov 2002 18:24:18 +0100, Dominik Vogt wrote: > > > > On Sat, Nov 09, 2002 at 05:35:40AM +0000, Mikhael Goikhman wrote: > > > To keep quality and consistency I follow these rules for our files > > > installed into bindir. I would like others to follow them too. > > > > > > 1) We have a special bin/ subdirectory for programs installed to bindir. > > > > > > 2) We don't install any program to bindir that does not have a man page. > > > > > > 3) We don't install any program to bindir without --help and --version. > > > > And "-h", "-?" and "-V" please. In the long run I would like to > > switch to GNU style long options. > > I think -V is a historical casus and it should better be -v, but let it > be -V...
As far as I know, -v is traditionally reserved for --verbose and -V for --version. I'll look that up. > But not -?, it is not even inputable in many shells, should be > escaped as -\?. Well. personally I've never even thought of using -?, but it was an old standard variant of -h that is preferredly used today. Anyway, I agree with Dan that every unknow option should print the usage message. > > > 4) The programs in the system's bindir should not have any extension. > > > > > > Extensions like .sh or .pl are good for files without +x permissions > > > so that a user could know what interpretter to run on these files. > > > Additional reasoning: > > > My /usr/bin has 2002 files. From 280 sh/bash scripts only 11 are *.sh. > > > > > > 5) The programs should have the "fvwm-" prefix for consistency. > > > > > > Additional reasoning: > > > My /usr/bin has 242 files in the dash form like "gnome-bug" and > > > and only 95 files in the underscore form like "pg_dump". > > > > > > I think many projects follow these rules. They lead to a better user > > > experience. > > > > Although I don't see rule 5 as mandatory, it is still better to > > follow some rules than to let chaos reign. One should also point > > out that only programs should be installed into bindir that are > > useful when they are exectued from a command line. Programs that > > do not fulfill this criterion belong into libexecdir. > > > > This is what I think it should look like for the current programs: > > > > source dir install dir > > --------------------------------------------------------- > > fvwm-bug bin bindir > > fvwm-config bin bindir > > fvwm-convert-2.2 bin bindir > > fvwm-convert-2.4 bin bindir > > fvwm-convert-2.6 bin bindir > > fvwm-menu-desktop bin libexecdir > > fvwm-menu-directory bin libexecdir > > fvwm-menu-headlines bin libexecdir > > fvwm-menu-xlock bin libexecdir > > fvwm-perllib bin libexecdir > > I am not sure where did you get such crazy idea. :)) >From the GNU coding standards ;-) > libexecdir is for loadable modules, it is specifically designed _not_ to > be in $PATH, because it is hardcoded into the main executable and used when > a module is loaded. > > All of the scripts above are designed to be run from the command line and > to be in $PATH. Actually, fvwm-perllib _must_ be in $PATH otherwise no > user modules in perl, at least the ones that do not harcode anything, will > work (ok, they may use fvwm-config instead, but they don't). I am not > speaking about reading man pages like "fvwm-perllib man". > > All of fvwm-menu-* scripts are a standard way in fvwm starting from 2.4.0 > to achieve four different tasks, like providing the KDE/GNOME integration > support, building all kinds of directory and web headlines menus and > designed to work under PipeRead, so they should be in $PATH. Yes, they are run from the command line, but it makes no sense to run them outside fvwm context. I guess one could fight lengthy flame wars about the question if that qualifies them for bindir or the "pure" path via fvwm-config/libexecdir should be taken. Whatever, I'll shut up now, especially I really couldn't care less what gets installed where. My only concern here is not breaking things that worked in the past. > > fvwm-root bin bindir > > build_dev.sh utils - > > configure_dev.sh utils - > > fvwm_make_browse_menu.sh examples docdir > > fvwm_make_directory_menu.sh examples docdir > > make_fvwmdist.sh utils - > > quantize_pixmaps bin ? > > rebuild_dev.sh utils - > > xselection bin - > > I think it is a good opportunity to remove quantize_pixmaps and xselection > all together. In any case they should not be installed into bindir, so > should not be in bin/. No objections. > > And while we are defining rules, I think every new script or > > program should follow the GNU coding standards with respect to > > handling and naming command line options, default options and the > > output of the -V/--version option. We can save a lot of trouble > > by using getopt_long() (yes, I know it's not portable - we need > > the getopt source file in the distribution). I even have a nice > > template for option parsing with getopt. > > > > P.S.: I have just removed all the "-blabla" options from > > fvwm-root. They were all introduced after 2.5.0 and can thus be > > removed without notice before 2.6. > > Actually supporting the -version form would not harm. I saw many shell > scripts do it, for example our own autogenerated ./configure. Before you > removed it, most (if not all) our bindir programs supported both variants. > But this is not very important. No, it doesn't hurt, but on the other hand they *will* be removed *everywhere* in 3.0. So, if we don't add them now, we have one tool less to worry about later. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
