![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
eftychia at 04:17pm on 2009-11-06Uh, did somebody just buy me a gift subscription to Science News? A copy of the current issue just arrived in today's mail ... and I did recently mentioned (and a little less recently) mention having been a reader of it in the past.
If so, thank you. A lot. I've missed it. It's a bit thicker now than I remember.
I could probably get all the same news from the web nowadays, but someties it's just easier -- feels more relaxed and recreational -- to read stuff like that on paper. And by just turning pages instead of scrolling up and down and then deciding which links to click next. (I love the web, but I'm glad we still have dead-trees publications as well.)
For folks who use command-line tools: if a command has both a "display version number" option and a "more verbose output" option, which of these is more intuitive (and/or less likely to be annoying)?
-v = version; -V = verbose
1 (25.0%)
-V = version; -v = verbose
3 (75.0%)
Doesn't matter; either is good
0 (0.0%)
Ew, both suck; use getopt_long() and spell it out
0 (0.0%)
Er, what? Ooh, clicky!
0 (0.0%)
People still bother with command-line interfaces?
(warning: I may mock you if you click this)
0 (0.0%)
If some combinations of command-line arguments might produce not-completely-obvious results, but those combinations are potentially useful so they should merely be warned about rather than disallowed, which of these seems more useful?
-w to turn on warnings for the least obvious dangers;
-W to add warnings just for folks not yet acclimated
to the joys of Unixy deliciousness
1 (25.0%)
-w to turn on wanrnings of all possibly confusing
combinations detected; -W to warn only about severe
gotchas
0 (0.0%)
All warnings on by default, with "did you really mean
that?" prompts, unless the user turns them off
with an "I know what I'm doing" option
1 (25.0%)
Only warn about data-destroying potential-gaffes,
and treat mere potential-inconveniences as "they
probably meant to do that
1 (25.0%)
I'm not sure ... but ooh, clicky!
1 (25.0%)
Let's say you have a bunch of files in a directory (say, "arbeau.abc", "machaut.abc", and "frtrad.abc" in a directory named "french") and some or all are hard-links to (not copies of) entries in another directory (perhaps "french/arbeau.abc" also appears as "dance/arbeau.abc" and "french/machaut.abc" is the same file as "songs/machaut.abc") ... and you decide to modify all the files in that directory ("french") in a batch, using a tool that replaces files with edited versions and optionally saves backups (named *.bak or *~). Which of these sounds like the most correct behaviour (most likely to be desired, least likely to induce cursing)?
Copy each file to its backup-name, then
overwrite the original with the edited
version (so dance/arbeau.abc is still linked to
french/arbeau.abc and thus reflects the changes).
This is what links are for.
2 (50.0%)
Heck, not only that, but it should try to ensure
that symbolic links behave as much like hard
links as possible in cases like this.
1 (25.0%)
Rename each file to its backup-name, then create a new file with the original name for the edited version (dance/arbeau.abc is now linked to french/arbeau.bak, and french.abc is a completely new file with no other links to it).
0 (0.0%)
Make it yet another command-line option, to choose between copy/overwrite and rename/create, and/or prompt the user to choose.
0 (0.0%)
It doesn't matter, because the only users likely to be using links that way in the first place are going to try it out with a couple of dummy files first to find out which way you're doing it.
1 (25.0%)
Wait, what's a "hard link"? Is that like an alias?[*]
0 (0.0%)
[*] Not really, but it's related. A symbolic link is like an alias. A hard link is where a single file on disk has two names -- an occasionally useful error in an MS-DOS filesystem, an established, intentional feature in Unix -- and neither filename is any more or less "real" than the other. I don't know whether recent versions of Windows have added this feature or not, but in older versions you could force it to happen, at the risk of CHKDSK "repairing" it later.
I'm not sure whether I'll get back to the project that sparked the questions in that poll (see below), but the responses will pertain to some future project too, I'm sure.
Despite the welcome arrival of a copy of Science News, it's been a discouraging week. The Mac won't boot, and it died just as I was fine-tuning the interface for a program that was nearly ready to share, beautifully comment, with a man-page and everything ... that I had not yet copied elsewhere to try compiling on a different OS, or to post yet. There was a lot else not backed up, but most of that will merely annoy and inconvenience me; this bit is the "somebody kicked over my masterpiece sand castle just before I finished it" kick in the gut. (Hmm. Much of what was backed up was backed up to DVD. I'm not sure yet whether any of my other computers can handle that. Experiments to put on my to-do list.)
Couple that with the main Linux workstation -- the bedroom machine -- which I hadn't been using much since I was given the Mac, no longer talking to its monitor, and I've been getting by with an itty-bitty Windows XP machine with a tiny screen and a so-so X server on it for the past few days, and it's been really putting a dent in my enthusiasm. So, in the immortal word of Charlie Brown: AAAUUUUUUGH!
(The bedroom Linux machine shows the POST messages on the monitor -- which is itself having major problems, but I have an even larger monitor to use ifwhen I ever feel capable of getting it up the stairs -- but at some point the screen goes blank and nothing I do to the keyboard or mouse will light it up again. I can SSH to it, and throw X apps to the itty bitty XP screen (a VAIO that only works when plugged into the wall), but I don't get the benefit of the decent-sized screen or the larger keyboard.)
The small screen is fine for web surfing and email; not so good for editing source in one window, editing docs in another, looking stuff up in a third, and viewing output in a fourth, or comparing two PS/PDF pages side by side. Or maybe I'm just spoiled from having a Mac to use for the past several months.
I haven't had the heart to start reconstructing a week of coding from scratch (get a filter working: a couple hours; add enough comments that I won't be embarrassed if anybody else sees it, usefully robust command-line arguments and options, and somewhat reasonable user documentation: a week) -- and I'm still clinging to the faint hope that the files can be recovered -- so I tried to dive back into composing and arranging, and am finding the tiny screen even more annoying for that than for programming. Or maybe I'm just too acutely frustrated and discouraged to cope with even small inconveniences right now. Maybe I'll feel differently about this in a month. But right now, it sucks.
The plan is to head down to Virginia to see whether
![[info]](https://stat.livejournal.com/img/userinfo.gif){kind=small}
justgus37,
who has more Mac tools, more Mac experience, and OS install
media, has any more success ressurecting the Mac than I've had.
Wednesday I wasn't feeling well enough to drive that far; last
night I got a late start and then ran into some kind of mess
that turned I95 and the Beltway into obstacles instead of arteries,
and turned back after it became clear I wouldn't get there at any
sane hour. So: trying again tonight, if I'm up to it, which at
the moment is iffy but I've still got an hour or so to decide.
(By the time I got home again last night, it hurt to steer,
and I've got power steering. But on the plus side, I got more
sleep this morning than the past couple of days, so let's see
what my body decides to do with that.)
I want my code back. I want my files back. I want my tools back. This business of knowing I need more backup media and a big disk for a live backup, but not being able to afford either ... well it's starting to wear me down.
(no subject)
Science News?
That was me. Damned if I'm going to put up with a world where the person who demonstrated to me that no matter how good you are, there's someone better can't read Science News. That said, their online edition is also quite good.
Since, for unknown reasons (best guess: my lack of OpenID credentials) your poll won't let me respond, my responses:
-v for verbose, -V for version
Only warn about data-destroying potential-gaffes, and treat mere potential-inconveniences as "they probably meant to do that"
Copy each file to its backup-name, then overwrite the original with the edited version (so dance/arbeau.abc is still linked to french/arbeau.abc and thus reflects the changes). This is what links are for.
(no subject)
DW polls are supposed to let people with LJ accounts respond to polls ... I'm not entirely certain what the mechanism for that is. (I'll experiment later.) Given that I've only gotten one response so far using the poll mechanism, I suspect you're not the only person having trouble.
(no subject)
(I was trying to decide if "I'm sorry for your loss" would be funny or not...)
(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?
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
At first blush, it seems the correct thing to do would be to follow the symbolic link to its destination and perform work on the file there, making the changes visible everywhere it's linked to -- the same effect as overwriting the contents of a hard link but via a different mechanism. But I really ought to think more about that first, in case there are repercussions (or conventions and expectations) I've overlooked. (And it does raise the question of whether the backup file should be placed next to the file the symbolic link points to, or next to the symbolic link the user told the program to operate on.)
Come to think of it, every time I've tried to use an alias in Windows to let me have the same file appear in two folders, anything I've done via the alias to alter the contents of the file has resulted in the linkage being broken, defeating my purpose in creating the alias in the first place (except when the point has been simply to provide a shortcut to an executable, which AFAICT is all Windows aliases are really supposed to be used for).
Hmm ... rename() will rename the link, not the destination, so rename-then-write-new-file should have the same effect whether it's a hard link or a symbolic link. Assuming fopen() calls open(), that'll read/write the destination of the link, so copy-then-overwrite should also produce the same results regardless of hard-vs-symbolic ... Ah. So as long as users expect the same behaviour for hard and symbolic links, my code doesn't have to try to distinguish between them: *whew*. Er ... at least in Unix/Linux/MacOS/etc. Let's see how long it takes me to find out whether this logic carries over to Windows easily or not.
(no subject)
I haven't done anything with aliai on Windows, except a few shortcuts I've created on my desktop at work. But it's a comfort there to know that Windows will assume I'm trying to delete the shortcut, not the source, when I want to clear it from my desktop.
And now that I come to think of it, I often *want* the Unix symbolic link to have a different name from the file it points to. So maybe I'd rather have "Make it yet another command-line option, to choose between copy/overwrite and rename/create, and/or prompt the user to choose."
(no subject)
(no subject)