command line vs gui
in [General Linux]
|
Prev: micro solution backpack cd-writer hell
Next: "...error while loading shared libraries: libg2c.so.0"
From: Tobias Brox on 11 Dec 2005 18:00 [Lee Sau Dan] > But the more competent people all know that it's a waste of time to > make it, because it'd be useless. I still think it could be useful for those who are using "find" seldom enough to forget the options and the syntax between each time, and who don't like to read the manual - plus all of those who have heard that find is a good thing, but who do not care reading the manual pages. Actually, I think there are quite many such users out there. > Tobias> Another thing, when doing things non-interactively, say, > Tobias> find . (...) -exec rm '{}' ';' (hm, actually find supports > Tobias> -delete - didn't know that) it is much easier to do > Tobias> mistakes than when first doing a find without side effects > Tobias> and then seeing the list and then removing the files. > Easy. In the place of -exec, use -print to have a dry-run. Any > *competent* user of 'find' knows how to do this. How often do you do that? Every now and then I do serious mistakes because I trust my own abilities too much. Anyway, it is not that easy when having lots of files. You could tail the output to less, head or tail or even wc, or write it to a file and do investigations on the file - but this kind of thing is actually much easier to do through a user interface. It would be neat to add a file counter there - so the user will at once see the head of the list and the size of the list up immediately, and if he would get cold feets, he can do different sortings, show different columns and browse up and down in the list before pressing the "delete"-button. > Tobias> For anyone beeing familiar with find, probably the user > Tobias> interface would not be much useful, but if nothing else > Tobias> the proposed user interface is a nice way of learning to > Tobias> use find. > That's why competent users won't want to design a GUI for find. ....which is probably pretty much why such a tool doesn't exist; it's not useful for the people who are competent enough to make it. > Tobias> I'm asserting that it's possible to implement this, but > Tobias> I'm not going to prove it. Sorting/unique-test is trivial > Tobias> using a high-level programming language or apropriate > Tobias> libraries. > Unix shell-scripting is a very high-level programming language. Who said the tool itself couldn't be written as a Unix shell? Though, I'd probably rather go for python or perl. > Tobias> Sort buttons on the file list would be a nice thing, and > Tobias> for the most fields and most people easier than to use the > Tobias> sort command. Actually, I think that there is no way to > Tobias> use 'sort' for sorting on the nth field in the > Tobias> space-aligned output one gets from "find -ls". > You're wrong. Study "man sort" yourself. Ok, so the default for the field separator is "any non-blank", and thus as long as the actual data always contain equal amount of spaces it will work. As far as I can see from "find -ls", the only field that can contain spaces is the file name, and it's the last thing, so you are right. Sort does not have any option for "sort from character #x", and that would often be useful when sorting space-aligned text. > How are you going to support the "load search" without parsing the > whole search query? And how are you going to represent in your UI a > query that your UI cannot express? Why should I need to represent it other places than in the right section (actual command + listing of files found)? -- This signature has been virus scanned, and is probably safe to read Tobias Brox, 69?42'N, 18?57'E
From: blmblm on 12 Dec 2005 02:00 In article <87hd9fof3h.fsf(a)informatik.uni-freiburg.de>, Lee Sau Dan <danlee(a)informatik.uni-freiburg.de> wrote: >>>>>> "blmblm" == blmblm <blmblm(a)myrealbox.com> writes: > > blmblm> So. Yes, I think that if you started learning English in > blmblm> kindergarten, that doesn't tell us much about your ability > blmblm> to learn it as an adult. (I think I've heard that there's > blmblm> a threshold age, below which it's much easier to learn new > blmblm> languages, especially the sounds, and it's somewhere > blmblm> around age 9.) > >But still, many HKers who learned English in the same education system >and environment as I do, do not learn it that well. Many of them has >a very Chinese accent. So what's the difference between them and you? You reject the most ego-boosting explanation (unusual ability on your part) :-), so it must be something else? > blmblm> That could be. I think the age of acquisition may also > blmblm> matter. What I have heard is that it's much more > blmblm> difficult to learn to speak a language without a > blmblm> non-native-speaker accent past that threshold age (9?). > blmblm> But perhaps you're right that it's always possible, just > blmblm> difficult enough that most people don't bother. > >I don't believe in this. I think it's doable, if you would dig into >phonetics or a person with good phonetics knowledge could help you get >rid of the accent. > >The major factor, I believe, is the amount of time you can devote to >learning a language. Before puberty, you don't need to earn for a >living. You don't have too much homework at school. You simply have >so much time. Further, you're driven by the motivation of >communicating with your playmates, watching TV, etc. There is a >strong motivation and lots of time to devote to. Well, yes .... This subtopic started when I disagreed with the claim that learning a new language was easy for adults. I *think* what you've been saying is that it doesn't take any special abilities, but it does take an investment of time and energy that a lot of people seem unable or unwilling to make? which puts us closer to agreement, I think, than might be apparent, since for me "easy" sort of implies "doesn't take much effort". [ snip ] -- | B. L. Massingill | ObDisclaimer: I don't speak for my employers; they return the favor.
From: blmblm on 12 Dec 2005 02:07 In article <874q5foeny.fsf(a)informatik.uni-freiburg.de>, Lee Sau Dan <danlee(a)informatik.uni-freiburg.de> wrote: >>>>>> "blmblm" == blmblm <blmblm(a)myrealbox.com> writes: > > >> Doing it in 1 search has another advantage: no duplicates in > >> the result list. > > blmblm> If the results of the two searches are supposed to be > blmblm> processed by two different actions, "no duplicates" is not > blmblm> really an advantage. My experiments suggest that only one > blmblm> of the actions will be performed, which might or might not > blmblm> be what one wants. > >It is still and advantage. The second query can be formulated in a >way to avoid generating the duplicates. That's a simple exercise in >Boolean algebra. And the search engine can take advantage of this "no >duplicate" filter to optimize the search. Even in the absence of such >optimization, you can optimize the network traffic by eliminating the >need to send the duplicates back to the caller once more. Well, what I meant was .... Here's a contrived example: find . -name "*.bak" -exec cmd1 {} ; -o -mtime -1 -exec cmd2 {} ; What should happen to a file that matches both search criteria? e.g, thing.bak created two hours ago? I think a naive user might expect both "cmd1 thing.bak" and "cmd2 thing.bak" to be executed, but in fact it will only be "cmd1 thing.bak", right? A less naive user will understand this, and presumably formulate a command that has the desired results for files that match more than one criterion, but .... That was the point I was trying to make -- that eliminating duplicates might produce results that would be surprising for some users, and not in a good way. -- | B. L. Massingill | ObDisclaimer: I don't speak for my employers; they return the favor.
From: blmblm on 12 Dec 2005 02:22 In article <dnib1u$256m$1(a)news.uit.no>, Tobias Brox <tobias(a)stud.cs.uit.no> wrote: >[Lee Sau Dan] >> But the more competent people all know that it's a waste of time to >> make it, because it'd be useless. > >I still think it could be useful for those who are using "find" seldom >enough to forget the options and the syntax between each time, and who >don't like to read the manual - plus all of those who have heard that >find is a good thing, but who do not care reading the manual pages. >Actually, I think there are quite many such users out there. Chalk up one person who agrees with you (me). What I like about your proposed GUI is that (if I understand a previous post) it shows the CLI equivalent, so people who use it often might eventually pick up enough of the CLI syntax to use the CLI. [ snip ] >Sort does not have any option for "sort from character #x", and that >would often be useful when sorting space-aligned text. Um, different versions of "sort" maybe? The one I use has this option. The old syntax, which doesn't seem to be in the man page any more, is "sort +0.9" to sort on the 10th position (and following). The newer syntax is apparently "sort --key=1.10". FYI, maybe. [ snip ] -- | B. L. Massingill | ObDisclaimer: I don't speak for my employers; they return the favor.
From: Tobias Brox on 12 Dec 2005 02:37
[blmblm(a)myrealbox.com] > Um, different versions of "sort" maybe? The one I use has this option. > The old syntax, which doesn't seem to be in the man page any more, is > "sort +0.9" to sort on the 10th position (and following). The newer > syntax is apparently "sort --key=1.10". FYI, maybe. This "key" is intended to be the number of the /column/ one wants to start with, not what character on the line. Say, sorting the following file by column #2, starting at character #15, is a very easy thing to do, but "sort" lacks that feature: 1. this is 6. a space aligned text 9. with three columns 2. just 5. to examplify that sort 8. doesn't handle it well 3. what more 4. can I say? 7. ... $ sort --key=15.16 < /tmp/stupid 1. this is 6. a space aligned text 9. with three columns 2. just 5. to examplify that sort 8. doesn't handle it well 3. what more 4. can I say? 7. ... I could sort by key #4, though, but it would require a change of the input: $ sort -k 4 < /tmp/stupid 3. what more 4. can I say? 7. ... 2. just to 5. examplify that sort 8. doesn't handle it well 1. this is 6. a space aligned text 9. with three columns -- This signature has been virus scanned, and is probably safe to read Tobias Brox, 69?42'N, 18?57'E |