Olaf van der Spek wrote: > Michael Stone wrote: > > Olaf van der Spek wrote: > > > Maybe you should look at this from the perspective of the user instead > > > of the perspective of the developer. > > > > By "from the perspective of the user" you mean "from the perspective of the > > user who doesn't want to use the proper tool and wants a completely > > unrelated tool to duplicate the functionality". > > So if I ask in debian-devel: "What is the recommended way to view a > file?", what will the answer be?
That would be on topic for debian-user not debian-devel. It is a user usage question. You would get a total of opinions equal to 1.357 times the number of responders recommending different tools. Get ten responders and you would have fourteen different recommendations. Possibly more! Because it is a personal preference. You can use any tool that you want to use. It is a free system. However even if you do not like any of the recommendations it doesn't change the fact that 'cat' isn't designed as a binary file browser. Trying to make cat into a binary file browser isn't the right answer. I observe that it is at these times, when the needs of the system does not fit the needs of the user, that people develop the tools which become the right tool for the job. This might be the perfect time to *develop* a good tool for your problem. Would we have 'rsync' if 'cp' bloated itself with all of the options of 'rsync'? Look at the feature list of rsync and that of cp and compare them. Ask yourself if you think cp with all of rsync's features would be small enough to be used on a small embedded system? Or if adding all of rsync's features to cp would kill the ability of using cp in a small embedded system? (In fact cp is already quite a bit too large as seen by the creation of busybox.) The 'cat' program is similar. It is used *everywhere*. Also changing the behavior of core programs has a very high multiplier. (Colloquially we might say it has high leverage or has high fanout.) Even if the likelihood of breakage for something is low the risk from that breakage is very high. A very small number multiplied by a very large number. The result has a large and unpredictable risk. Like a surgical procedure with small and questionable benefit. Ninety nine out of a hundred patients have no side-effects. But one out of a hundred patients die from it. Would you have the procedure? No single straw breaks the camel's back. It is the sum accumulation of so very many small straws that overloads the camel. > And what is your recommendation? I don't want paging. Others have suggested 'cat -v' (I personally don't like it for the above reasons but, it has been around for a long time). I thought the 'vis' and 'unvis' programs from 4.4BSD were the better choice. They were invertible. For portability I would probably use 'sed'. (He says portability and then uses a POSIX character class... :-) sed 's/[^[:print:]]/?/g' Personally I use 'strings' for extracting printable strings from mixed text and binary files. strings mixedbintextfile | head head mixedbintextfile | strings The order can produce different results and each behavior may be desirable at different times. > What is the major usage of tail? To the terminal or not to the terminal? Certainly not to the terminal. The 'tail' program is widely used in scripts. Although it is also often used in a terminal I would think that pagers would be more common for that purpose. I would guess that usage in scripts is the more often case. It is impossible to tell without something like an invasive popcon instrumented system where the program reported how it was used. A good research topic. But remember that you can only type so fast but systems across the world net run scripts continuously. It is hard to compete with the mechanized workforce. Again, use of 'strings' here is probably what you want. tail -f /var/log/mysql/mysql-bin.* | strings Of course I like the 'strings' program but I am sure that others would have different but equally valid suggestions for viewing binary data. If I am just looking at files I usually just browse the file with emacs since it handles binary data in a way that makes sense to me. Plus the emacs 'M-x hexlify-buffer' works acceptably for me. Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
