![]() ![]() #! on first line interpreted by execve(2). But I usually don't recommend doing that it might make sense if your program could be used as a script interpreter using shebang i.e. bash invoked as rbash has a different behavior ( restricted shell). In rare cases you might also use argv (by using symlinks on your program), e.g. If your software is a series of related command-line programs, take inspiration from git (which you surely use as a development tool), which accepts git help and git -help and have many git subcommand and git subcommand -help I would recommend not following their bad habits (unless you are making some better variant of them). dd, or even sed) have weird command arguments for historical compatibility. gcc) accept indirect argument lists, so is meaning read program arguments from somefile.txt this could be useful when your program might accept a very big lot of arguments (more than your kernel's ARG_MAX)īTW, you might even add some auto-complete facilities for your program and usual shells (like bash or zsh) If your program uses isatty to test than stdin is a terminal (and behave "interactively" in that case), provide an option to force non-interactive mode, likewise if your program has a GUI interface (and tests getenv("DISPLAY") on X11 desktop) but could also be used in batch or command line. Use - as separator between options & file or other arguments Mimic the behavior of similar programs by reusing most of their options conventions in particular -n for dry run (à la make), -h for help, -v for verbosity, etc. Often use - for standard input or output (if you can't do that, handle /dev/stdin & /dev/stdout even on the few operating systems not having them) so your -argument:value proposal is weird, and I don't recommend doing that. Show these option lists on option argument error.Īccept -a short argument (single letter) and have some equivalent -long-argument, so -a2 -long-argument=2, -long-argument 2 of course you could have (for rarely used options) some -only-long-argument name for modal arguments without extra options -cf is generally handled as -c -f, etc. in that case list the most common ones and explicitly refer to some man page or some URL) and default values of options, and perhaps important (and program-specific) environment variables. Have the -help message list all the options (unless you have too many of them. I curse the authors of software not understanding -help, I hate them (because prog -help is the first command I am trying on a new program)! Often -help can be abbreviated as -h most of them), I would recommend using the GNU coding conventions (which also lists common argument names) and look into the POSIX utilities guidelines, even for proprietary software:Īlways handle -version and -help (even /bin/true accepts them!!). Linux, MacOSX), at least for programs possibly started in a shell terminal (e.g. As I want this question to be operating system and programming language independent the answers appearing here can be a valuable lesson for other developers. Maybe it qualifies to the community wiki (I do not know if existing question can be converted with answers). To more advanced Stack Exchange users: I wanted this question to be general. Not finding in the Internet what I want I asked here. It is not very important from the side of the business but as I agree with what Kilian Foth said I do not want my application to be a pain for a user. However some advanced administrators may want to configure the application on their own. We will provide front-end interface to manage the devices. Devices will have Windows 8.1/10 installed. Applications are written using Qt Quick 5 (C++, QML, JS). We are working on an application which will be used in public places (touch totems, tables). I think they are all the same for all kinds of applications. ![]() The question is about a good habits in general. However I think they should not affect the answers. Are there some commonly known rules which I should follow while designing command line arguments (other than if it works it is OK)?Īsked for some more details I will provide it. ![]()
0 Comments
Leave a Reply. |