SOLUTION (Was: Unix handles file extensions "very poorly"?

Date: Sat, 17 Dec 2011 14:16:05 +0000 Subject: Re: SOLUTION (Was: Unix handles file extensions "very poorly"? From: lproven at gmail.com To: cctalk at classiccmp.org On 17 December 2011 13:28, Dan Gahlinger <dgahling at hotmail.com> wrote: Yes, of course. For manipulating DOS floppies, or for running DOS apps. But they are, obviously, *not shells.* So, no, I do not use them for attempting to manipulate Unix files. Look, Unix/Linux has replaceable shells and comes with a choice of them: bash, zsh, tcsh, csh, etc. etc. This is well-known. What I am arguing for is another one, but one that uses a CLI that is approximately syntax-compatible with that of the industry-leading OS, the OS that runs on approximately 95% of the desktop, laptop and server computers in the world and has done for 25y now. I know that this CLI is less powerful and less flexible and less capable than the Unix one. I am not arguing that. What I am arguing is that the Unix one is hard work. It's complex, it takes time to learn - and, I'd say, a certain mindset, too - and it's also quite dangerous if you're not careful. It is, as all these "rm *. o" examples illustrate, very easy to accidentally do things you didn't mean to because it's so terse and the commands can do so much. It can do many brilliant and wonderful things that I don't want to do. :?) But it is often notably poor at /easily/ and /simply/ doing the stuff I do on a daily or weekly basis, like, say, searching recursively through users' home directories, finding, moving then later erasing all the temporary files abandoned by MS Office because it's too crap to clean up its own detritus after itself or even keep its temp files in the designate temp-files directory. If I can specify *.foo as the source of a command then I damned well want to specify *.foo as the /destination/ of a command as well. I do not /care/ about how the shell is implemented, I want it to work in a simple and obvious fashion. If *.foo matches all files called (something)(full stop)('foo') in one position in the command then it is natural and obvious that it should /also/ match (something)(full stop)('foo') in /any other position in the command as well/. It does on almost every other CLI OS I have ever seen, from RSTS to VMS to CP/M to DOS to Windows 7. /Pace/ different wildcard operators and things it does on AmigaOS and Acorn RISC OS and so on as well. On every Unix shell I've seen (i.e. since the late 1980s), it doesn't. Because Unix doesn't work that way. It's special. It does things differently. Well, that's fine. I am not arguing for the removal of all other shells except my notional DOS-like one. Good gods no. I'm just saying that, for all its limitations, the DOS-type method does actually have its uses and indeed its *benefits*. I honestly think it's easier - easier to learn, easier to use. And given that DOS-type systems run on 95% of x86 hardware, and that most people in IT only use DOS-type x86 systems and know nothing else, then there's a fairly strong case to be made that this way works and is good enough. Perhaps it's another instance of the "worse is better" argument. http://en.wikipedia.org/wiki/Worse_is_better I'm not saying it's crap. I'm saying it's more difficult, yes. Ah, but none of those sell roughly ten times more than all the Unixes in the world ever put together, do they? None of those utterly dominate commercial, charitable and governmental computing. None of those are the de facto standard, so overwhelming that even the surviving RISC UNIX boxes today use the buses and the interface connectors and the video and networking standards, and the storage media, and the disks and the RAM, *set by the x86 PC.* Sure, if that's what you want, fine. Users? Yes, in large part. Admins? No, actually, that is changing, fast. Modern versions of MS server tools are graphical wrappers around command lines, and when you perform an operation, they show you the command line first so that you can learn to do it yourself. The big new thing in Windows servers is the massive engineering effort to separate out the kernel and the GUI, the server application layers from the presentation layers. There are now CLI-only versions of Windows Server (although they retain the windowing system, thus far), and CLI-only versions of the big server apps, so that you can run them on headless boxes hosted in VMs and manage them remotely. Yes, it means MS is trying hard to catch up with where Unix has been for decades, yes yes. We know. But still, it's happening. Finally, MS is learning some stuff from the way things are done on the older OSs, the ones in long trousers that were established before Tim Paterson even wrote QDOS. Nope. But I've done it myself. :?) Oh, yes, absolutely. But they're happy with their GUIs; leave them to it. I'm talking about a tool to make life easy for the legions of Windows techies out there to adapt to the proliferation of free Unixes. Well, a bit. That's just a thought experiment. Mostly I am trying to justify my own preferences. :?) -- Liam Proven ? Info & profile: http://www.google.com/profiles/lproven Email: lproven at cix.co.uk ? GMail/GoogleTalk/Orkut: lproven at gmail.com Tel: +44 20-8685-0498 ? Cell: +44 7939-087884 ? Fax: + 44 870-9151419 AIM/Yahoo/Skype: liamproven ? MSN: lproven at hotmail.com ? ICQ: 73187508