Augh! I am running directly into -v vs -V at work (and it's my damn JOB to make a decision on it). Sympathies.
The rules of thumb I am using: * lower case options get used more than upper case. So if you're going to be doing verbose more than version, make verbose -v. Capital letters mean 'big' or 'inverse' or 'unusual'.
* capital letters feel like switches, lower case letters feel like options. (-V vs. -v3). This would lean toward -v for verbose if you have multiple levels of verbosity as we do.
I think we ended up settling on -v[] for verbose, "help" or "-version" for version. (But -V might still work. The problem I'm having at work is it's a perl script which dynamically looks up another perl script based on the user's environment, then calls a third perl script, which in turn calls Java code. And the switches go through to different parts of that, depending. So it's hard for me to keep track of everything. And did I mention each of those scripts is written by a different person?) If possible, also support -version and -Version and --version and...
-w: If something has a -w flag I will expect it to be 100% anal. If I turn on warnings I want you to warn me, not to "often" warn me. I'd also like some way to make that the default (a la "#!/usr/bin/perl -w"). I haven't seen a -W flag used for 'show me egregious warnings'; maybe you could have warn levels, -w1, -w2, etc.
Backups: for some reason, I expect backups to be in cwd, not in the directory of the file I'm editing. So for a hard link to somewhere else, it'd be next to the link, not next to the file. This does seem to lead to a surprising result, however! I think 'best' might be to put the backups next to the original of the files; it'd be polite to make a hard link for the backup, too, but maybe that's just twice as much to clean up once you've verified things worked correctly.
I try very very hard to avoid having hard links on my system, because I am always surprised by behavior surrounding them. I would at the very least expect a warning in this case.
These are tough decisions, and make up about 30% of my work day these days. Funny, innit?
I drafted a longer reply which got lost in a browser hiccup.
I find myself much less often surprised by behaviour regarding hard links than by stuff that happens with symbolic links ... so I use hard links more often. I find this difference in perception intriguing.
"I expect backups to be in cwd, not in the directory of the file I'm editing. So for a hard link to somewhere else, it'd be next to the link, not next to the file. This does seem to lead to a surprising result, however! I think 'best' might be to put the backups next to the original of the files [...]"
Er ... except that with a hard link, the link is the file (all links to it are equally "the real file").
I know I can get a link count for a file. Is there any reasonably fast way to locate all other links to a file? I can exec 'find' to search the rest of the filesystem for files with the same inode number, but on any realistically-sized, moderately full hard disk, that's going to be ssslllooowww. (I didn't spot anything likely-looking using "man -k link".)
User interfaces are the parts of design I dread, because I know how much bad or mediocre ones annoy me, and I'm not at all confident that my UI design skills are good enough to meet my own standards. Even, once we get into details like this, a command-line UI.
Better that such decisions are in the hands of someone who recognizes that they're tough, than the responsibility of someone who thinks they're easy because they're unimportant, eh?
(no subject)
The rules of thumb I am using:
* lower case options get used more than upper case. So if you're going to be doing verbose more than version, make verbose -v. Capital letters mean 'big' or 'inverse' or 'unusual'.
* capital letters feel like switches, lower case letters feel like options. (-V vs. -v3). This would lean toward -v for verbose if you have multiple levels of verbosity as we do.
I think we ended up settling on -v[] for verbose, "help" or "-version" for version. (But -V might still work. The problem I'm having at work is it's a perl script which dynamically looks up another perl script based on the user's environment, then calls a third perl script, which in turn calls Java code. And the switches go through to different parts of that, depending. So it's hard for me to keep track of everything. And did I mention each of those scripts is written by a different person?) If possible, also support -version and -Version and --version and...
-w: If something has a -w flag I will expect it to be 100% anal. If I turn on warnings I want you to warn me, not to "often" warn me. I'd also like some way to make that the default (a la "#!/usr/bin/perl -w"). I haven't seen a -W flag used for 'show me egregious warnings'; maybe you could have warn levels, -w1, -w2, etc.
Backups: for some reason, I expect backups to be in cwd, not in the directory of the file I'm editing. So for a hard link to somewhere else, it'd be next to the link, not next to the file. This does seem to lead to a surprising result, however! I think 'best' might be to put the backups next to the original of the files; it'd be polite to make a hard link for the backup, too, but maybe that's just twice as much to clean up once you've verified things worked correctly.
I try very very hard to avoid having hard links on my system, because I am always surprised by behavior surrounding them. I would at the very least expect a warning in this case.
These are tough decisions, and make up about 30% of my work day these days. Funny, innit?
(no subject)
I find myself much less often surprised by behaviour regarding hard links than by stuff that happens with symbolic links ... so I use hard links more often. I find this difference in perception intriguing.
"I expect backups to be in cwd, not in the directory of the file I'm editing. So for a hard link to somewhere else, it'd be next to the link, not next to the file. This does seem to lead to a surprising result, however! I think 'best' might be to put the backups next to the original of the files [...]"
Er ... except that with a hard link, the link is the file (all links to it are equally "the real file").
I know I can get a link count for a file. Is there any reasonably fast way to locate all other links to a file? I can exec 'find' to search the rest of the filesystem for files with the same inode number, but on any realistically-sized, moderately full hard disk, that's going to be ssslllooowww. (I didn't spot anything likely-looking using "man -k link".)
User interfaces are the parts of design I dread, because I know how much bad or mediocre ones annoy me, and I'm not at all confident that my UI design skills are good enough to meet my own standards. Even, once we get into details like this, a command-line UI.
Better that such decisions are in the hands of someone who recognizes that they're tough, than the responsibility of someone who thinks they're easy because they're unimportant, eh?