Nobody has spoken up for anything below.

On 03/12/11 2:08 PM, Liam Proven wrote: Right -- you should be able to find it in used bookstores where you are. ...they still exist, right? :/

--Toby

Used bookstores NEVER carry computer stuff, too out of date quickly. Nor do libraries.

On 12/2/2011 10:46 PM, Dave McGuire wrote: Good pick me a good book on computer hardware ... skip the intel products, windows and unix clones. What is left in the classic department?

As I write I am on my easy hinge from an excellent early Yule party. Mine host is a book dealer, sells a lot on Abe,& works solely from home with no shop.

- LP

Joys of predictive text entry on a keyboardless smartphone. Er, when drunk. That was /meant/ to say "I am on my way home..." 8?)

On 4 December 2011 18:54, Liam Proven <lproven at gmail.com> wrote: ne h no Joys of predictive text entry on a keyboardless smartphone. Er, when

drunk. That was /meant/ to say "I am on my way home..." 8=AC)

----- Original Message ----- From: "Tony Duell" <ard at p850ug1.demon.co.uk> To: <cctalk at classiccmp.org> Sent: Tuesday, December 06, 2011 8:30 PM Subject: Re: Mac/Mac Programming/Cocoa/HyperTalk Books free - Melbourne Most mobile phones (atleast the ones I have seen) have 2 options - predictive text (T9 mode on my 8 year old mobile phone) and ABC mode. There should be a way to switch it to ABC mode, though some mobiles have predictive text on as default (so you have to turn it off every time you need to text). I have yet to meet anyone that actually likes predictive text.

I don't really understand why any techie dislikes it, TBH. It is /vastly/ easier than, say, learning to understand how Unix wildcards work, let alone regular expressions or something - both things which I've not yet mastered after more than 20y of effort.

What is so tough is the way that the shell expands them, not the command. I am assured this is wonderfully useful for many people but for me it's a complete PITA. For instance, I frequently need to do things like: REN *.log *.old ... which works fine on DOS, Windows and most other OSs but doesn't work on Unix/Linux. In general, because file extensions are a sort of grafted-on afterthought on Unix, I find it handles them very poorly, whereas they were and remain integral to DOS-based & Windows-based systems - i.e. about 95% of the machines I support.

My current plan is to train as a TEFL teacher and spend a few years roaming the world, learning new languages and living in exotic places. After that, who knows?

What is so tough is the way that the shell expands them, not the command.

On Sat, 10 Dec 2011 19:23:54 +0000 Liam Proven <lproven at gmail.com> wrote: Yes. And this is no surprise, given that Unix is an OS programmed by programmes who wanted a nice environment for programming. :-)

BTW: A friend of mine knows all and everything about Windows. But he simply can't wrap his mind around Unix. Just like you.

On Dec 11, 2011, at 9:23 AM, Liam Proven wrote: Or, as the saying goes: "Unix is plenty user-friendly, it's just picky about who its friends are."

And yet it's very friendly. Arguably the friendliest, most accessible

I am sure you're right. I have never tried, personally, despite using OS X for a decade now. Never encountered the need. I once had my BBS software running under Mac OSX, many years ago. I tried

I am sure you're right. I have never tried, personally, despite using OS X for a decade now. Never encountered the need.

On 12 December 2011 15:31, Mark Benson <md.benson at gmail.com> wrote: If you need to run non-Aqua or non-OS X-native apps, then you're probably running the wrong OS. It has been axiomatic for decades that you choose the apps you need to fit your requirements, then pick the best OS to support them and buy whatever hardware it needs. I find OS X a great Internet client OS and a good solid productivity platform. (I don't actually run it as such day-to-day, as I don't have any current or recent Mac hardware - all mine are PowerPC or MC68K. I won't pay the prices for new Macintel H/W.) But if I wanted to build a firewall or an workgroup server, it would not be on the shopping list at all. Horses for courses, you know! It is a superbly friendly OS and I think its adoption figures, and the users' responses, more than bear that out. It's not your grandfather's Unix, nor is it Windows or Linux, and if you need them, then no, it's a poor choice. [Roars with laughter] This must be some strange new usage of the word "friendly" that I wasn't previously aware of. ;?)

On Mon, Dec 12, 2011 at 4:16 PM, Liam Proven <lproven at gmail.com> wrote: Well, yeah. ?I did just that. ?I used Debian instead. ?It would have been convenient if they ran on OSX, I could run one less computer.. save power, that sort of thing.

However, I think it *should* work I got my dad (who is 80) to buy a Mac, thinking that he could use it. ?No luck. (;

On 12 Dec 2011, at 14:29, Liam Proven <lproven at gmail.com> wrote: Lucky. A lot of us have and it rarely ends well, or if it does the part in the middle is a nightmare.

The point was that your assertion that it's a 'friendly' OS is really only skin deep. Actually it's a awkward bastardisation of BSD UNIX with a friendly *GUI*.

I'd nominate VMS as friendly way before OS X's so-called UNIX implementation.

Well Apple put more effort into OSX then they did with their first UNIX (A/UX).

OSX pre 10.3.x sucks.

On 12/12/2011 09:10 AM, Mark Benson wrote: It was even a horrible pain back in NeXTSTEP. Apparently Netinfo had a hardcore devotee (I don't recall who it was) within Apple who just Would Not Let It Go for way too long. It was a bad idea in NeXTSTEP, and an even worse idea in OS X. Good riddance.

On 12/12/2011 07:26 PM, David Riley wrote: Whew, that's a real head-shaker. To steal a phrase from my friend Jon...there are lots of people in this industry who would be better suited to making sure my burger is cooked thoroughly.

-Dave

I always assumed it was Steve. Or, wild-ass guess: Tevanian?

Is it really worse than NIS/YP (in fact NetInfo gives me the impression it was meant to supersede it?)

NEXTSTEP and the NeXT workstation was "intended" to sweep all before it. Including SunOS, Sun and other proprietary Unix workstations. It probably deserved to. Imagine if it had succeeded :)

I meant workstations, of course.

For one thing, we wouldn't have Macs anymore, just NeXT workstations. Wait a minute ...

I doubt sweeping aside anything based on its being proprietary[%] was part of the intent, especially since NeXTen included undocumented hardware, notably the blitter, and NextStep included closed-source components, notably the DPS server.

[%] Not _quite_ what you said, but your wording seems to indicate, to me, that this is what you intended. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Is it really worse than NIS/YP (in fact NetInfo gives me the impression it was meant to supersede it?)

----- Original Message ----- From: "Liam Proven" <lproven at gmail.com> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Sent: Monday, December 12, 2011 8:05 AM Subject: Re: Mac/Mac Programming/Cocoa/HyperTalk Books free - Melbourne > On 11 December 2011 14:32, David Riley <fraveydank at gmail.com> wrote: > > Ahahaha! Well, true. But it's changing. Don't forget that Mac OS X is > officially UNIX?, as approved by the Open Group. And it's the most > widely-licensed UNIX? there has ever been, either in terms of numbers > of users or in terms of number of systems. I suspect that its sales of > several hundred million licences means that it has outsold /all/ other > commercial Unices there have ever been /put together/. > > (That's excluding the rather greater number of iPhones, iPads and iPod > Touches, which run the same core OS with a different GUI.) > > And yet it's very friendly. Arguably the friendliest, most accessible > modern desktop OS. > > Also, it might amuse ClassicCompers to know that there is now a > community of people interested in running "classic" early versions of > OS X on older Macs, especially PowerPC Macs. Our own Cameron Kaiser > being something of a hero in this regard. ;?D

Well Apple put more effort into OSX then they did with their first UNIX (A/UX). OSX pre 10.3.x sucks.

----- Original Message ----- From: "Liam Proven" <lproven at gmail.com> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Sent: Monday, December 12, 2011 8:05 AM Subject: Re: Mac/Mac Programming/Cocoa/HyperTalk Books free - Melbourne Well Apple put more effort into OSX then they did with their first UNIX (A/UX).

OSX pre 10.3.x sucks.

A friend who rented a room off me for a couple of years wa s the first to say this to me. I would often go to him with Linux problems and queries and it took him quite some time to wrap his head around the idea that I was powerfully averse to scripting and coding. It is very alien to the Unix mindset, which is, yes, by programmers for programmers. This makes it sometimes very unfriendly to non-programmers. As this particular friend said to me: "it is only now that I am starting to understand how /deeply/ bizarre some of this stuff must seem to you, as a non-programmer!"

:=ACD Hurrah! It is not just me!

On Sun, Dec 11, 2011 at 02:23:14PM +0000, Liam Proven wrote: Yes, Unix evolved, among other things, as a tool hacked on by the folks that where actually using it. And in those days, those weren't exactly graphics designers, english majors or musicians. So it was build and improved by programmers, sysops, researchers and so on to be a useful tool for what they were doing.

Hehe. If you are in the programmer/systems engineering mindset, it is all perfectly logical and is in fact an incredible powerful tool. If you are not ... well, old, bearded men mumbling incomprehensible things over boiling and smoking cauldrons come to mind ;-) No, it is not just you. I'm sure there are plenty of people who just can't really grok Unix. As well as people who just love it. ;-) Fortunately, there is room for both of them.

On Mon, 12 Dec 2011 13:18:35 +0000 Liam Proven <lproven at gmail.com> wrote: The Unix of the 80'is was BSD. It was more advanced then SysV in many ways. (TCP/IP networking e.g.) Only when the founding of the CSRG at UCB and thus BSD came to an end, vendors switched to SysV. BSD heavily influenced anything that folowed it. E.g. the socket(2) API, vi(1), lpr(1), ...

Solaris is a child of the early 90'is. SunOS, its predecessor, was BSD. AIX is no real Unix at all. It just happens to look a bit like Unix. ;-) IBMs AOS was a BSD port. SCO, yes, SysV. IRIX, SysV.

OSF/1 is a MACH kernel

with lots of BSD on top. You can realy feel that Ultrix, its predecessor in the 80'is, was a BSD. I am a BSD person and I immediately felt "at home" when I touched OSF/1 first.

There isn't much difference betwen SysV and BSD these days. BSD got things like SysV shared memory, SysV got socket(2), ...

Well. Thats why I say: Linux evolved from a free Unix clone for Unix lovers into a bad Windows surrogate for M$ haters. ;-)

On Mon, 12 Dec 2011 13:18:35 +0000 Liam Proven <lproven at gmail.com> wrote: Well. Thats why I say: Linux evolved from a free Unix clone for Unix lovers into a bad Windows surrogate for M$ haters. ;-)

On Tue, 13 Dec 2011 04:12:53 +0100 Alexander Schreiber <als at thangorodrim.de> wrote: Sure, you can replace GNOME / KDE with twm... But that is not what I am talking about. It's the way Linux even feels from the command line. All too often shell scripts start with #!/bin/sh where #!/bin/bash would fit better...

Mysterious "configuration wizards" layered on top of standard Unix configuration files,

poor man-pages

, aliases like rm='rm -i' in the default .profile,

locked out root-accounts, so that you can't log into the machine even on the text console to fix a broken X11 or NIS,

no real single user mode,

^C not working at boot time, ...

On 13 December 2011 17:18, Jochen Kunz<jkunz at unixag-kl.fh-kl.de> wrote: But the default shell /is/ bash in almost every distro I've seen...?

Not seen that. Also a problem on real commercial Unix sometimes.

Very good safety net for newbies. Ditto, and a decent security measure too. A Debian issue not an Ubuntu one, no?

What would you have it do? Do remember that Ubuntu is "Linux for human beings" - for newbies and Windows users, *not* for Linux experts. There are *lots* of distros for them.

The only advantage texinfo has over nroff -mandoc is slightly more readable source code.

(And now that my trolling quota for the week is satisfied.... :) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

I must be the last person on earth who uses and adores tcsh. On a new system it's the first thing I install if it isn't there.

> I must be the last person on earth who uses and adores tcsh.

You're WEIRD. ;-)

Not to try to outweird anyone, but I have my own shell, a BSD csh with substantial hackery, mostly a command-line editor. But the answer to "Am I the only one who..." is "no", so there must be someone else who carries around a private shell based on patches applied to a widespread shell....

/~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

[eyebrows shoot up] Oh MY!!

I must be the last person on earth who uses and adores tcsh.

Oh good :)

Most Linux distros I've seen have very good man page sets. And even better: Texinfo! (Yes, I proudly fly the Team Texinfo flag...)

On 13/12/11 11:04 PM, David Riley wrote: That's odd. I thought you'd prefer turgid, rambling, incorrect crud! :)

That's odd. I thought you'd prefer turgid, rambling, incorrect crud! :)

On Wed, 14 Dec 2011 00:48:15 +0000 Liam Proven <lproven at gmail.com> wrote: It would be acceptable as a security measure to restrict root login to the local text console. This prevents "missuse" of the root account but makes the system accessible in the event of a failure. If e.g. NIS breaks you can't get into a Ubuntu machine to fix the problem. All you can do in that situation is to hit the reset button and boot single user. But that is an other story...

GenericUbuntuNonRootUserPrompt% sudo vi (while in vi) :shell

It was thus said that the Great David Riley once stated: I never tried, figuring that they just might lock those out.

GenericUbuntuNonRootUserPrompt% sudo vi (while in vi) :shell

Oh hell, SunOS4 (the BSD-based one!) doesn't even do that! It mounts the filesystems before giving you a single-user shell.

On 12/14/2011 02:11 PM, Jochen Kunz wrote: Then don't run Debian. ;) I run Ubuntu (yes I know, Debian-based) and I've NEVER seen such a "wizard" pop up, in probably two hundred runs of "apt-get install".

Oh yes, there are quite a few of those (now that I understand what he means). Examples: - msttcorefonts - Sun JVM - gdm, lightdm or other change of dm

On Thu, Dec 15, 2011 at 5:45 AM, Liam Proven <lproven at gmail.com> wrote: My reaction the first time I tried to install the Sun JVM and it popped up this interactive thing was a loud and resounding WTF?

[snip] Hehe. If you are in the programmer/systems engineering mindset, it is all perfectly logical and is in fact an incredible powerful tool. If you are not ... well, old, bearded men mumbling incomprehensible things over boiling and smoking cauldrons come to mind ;-)

On 12/11/11 8:25 PM, "Alexander Schreiber" <als at thangorodrim.de> wrote: My cauldron does not smoke (I have a proper vent on it).

On 12/11/11 8:25 PM, "Alexander Schreiber" <als at thangorodrim.de> wrote: Are you accusing me of mumbling? :-) -- Ian

For instance, I frequently need to do things like: REN *.log *.old ... which works fine on DOS, Windows and most other OSs but doesn't work on Unix/Linux.

On 12 December 2011 03:27, Ethan Dicks <ethan.dicks at gmail.com> wrote: Would that not look for 2 files, called dot-log and dot-old?

On 8 December 2011 21:03, Dave McGuire <mcguire at neurotica.com> wrote: What is so tough is the way that the shell expands them, not the command. I am assured this is wonderfully useful for many people but for me it's a complete PITA. For instance, I frequently need to do things like: REN *.log *.old ... which works fine on DOS, Windows and most other OSs but doesn't work on Unix/Linux.

In general, because file extensions are a sort of grafted-on afterthought on Unix, I find it handles them very poorly, whereas they

were and remain integral to DOS-based & Windows-based systems - i.e. about 95% of the machines I support. I've been bending my brain against it since 1988. I doubt it's going to stick now!

Windows knowledge has to be updated every few years as MICROS~1 change everything, and I don't really like Windows any more anyway, even if I know it better than anything else.

Unix knowledge helps me out on Linux but I am a bit of a Unix-hater

really, at heart, and I have never managed to truly master shell or C or Perl or regexps or any of the core Unix toolkit.

Linux has fixed and improved lots of things, but it's still the same ugly, hostile old system underneath.

OSs I really /liked/ at some time or for some reason included Acorn RISC OS, BeOS, classic MacOS, OS/2, Psion EPOC, NewtonOS and Novell Netware 2 and 3. And VMS, I suppose, but I only ever scratched the surface. And all of them had lovely aspects that I cherished but also terrible *terrible* problems and weaknesses as well. All are essentially dead and gone now.

On 12 December 2011 04:17, Alexander Schreiber<als at thangorodrim.de> wrote: Yes, I know. It's not that, I have no problem with that. The thing is that in the<ironic>wonderful world of the Web</ironic>, extensions are once again part of the deal - stuff like .html and .jpg and .png and whatnot all suddenly become very significant, even if the server and client are both Unix machines.

Plus, Unixes such as Mac OS X use extensions as important metadata, as must any Linux which interoperates with Windows - which is to say most of them. Extensions are important to LibreOffice and so on, for example.

>> were and remain integral to DOS-based& Windows-based systems - i.e. >> about 95% of the machines I support. >>...

I have always loved type/creator codes, and was very unhappy with Apple for removing them in 10.6 (but I'm 10.4 forever, so I guess it's not really my concern). The gap was that the core OS did not provide an easy way to manipulate this consistently, requiring a cavalcade of minitools (or a trip to ResEdit) to set them the way you wanted. But I loved being able to force certain files to automatically open in different apps if I wanted to, and at least for a time OS X gave you the choice.

I have always loved type/creator codes, and was very unhappy with Apple for removing them in 10.6 (but I'm 10.4 forever, so I guess it's not really my concern). The gap was that the core OS did not provide an easy way to manipulate this consistently, requiring a cavalcade of minitools (or a trip to ResEdit) to set them the way you wanted. But I loved being able to force certain files to automatically open in different apps if I wanted to, and at least for a time OS X gave you the choice.

Seriously? If you think Xcode is "great dev tools", then you need to get out more.

(and I think the UI overhaul in [Xcode] 4.0 was a major step backwards).

I feel like XCode used to be *better* dev tools. Honestly, I was most fond of medium-early versions of CodeWarrior (before OS X, before OS 9, really; the early "pro" versions), though that may be nostalgia talking more than accurate recollection. XCode, like everything else, seems to have bloated and gotten creaky with age (and I think the UI overhaul in 4.0 was a major step backwards).

I can't stand Xcode 4, it seems to have been written by someone who doesn't understand IDEs. I'd sooner use Eclipse. I could barely tolerate 2.x. For that matter, Objective-C drives me crazy. I use CodeWarrior 7 for Classilla and frankly there's no Mac development tool that even comes close. The debugger is delightful, if "debugger" and "delightful" can ever occur in the same utterance, and it integrates well with MPW and all the other build tools that Jobs II Apple swept out. The programs I create on OS X all compile from the command line. If I absolutely have to use Xcode to build something, it's with xcodebuild, not with GUI Xcode.

I have always loved type/creator codes, and was very unhappy with Apple for removing them in 10.6 (but I'm 10.4 forever, so I guess it's not really my concern). The gap was that the core OS did not provide an easy way to manipulate this consistently, requiring a cavalcade of minitools (or a trip to ResEdit) to set them the way you wanted. But I loved being able to force certain files to automatically open in different apps if I wanted to, and at least for a time OS X gave you the choice. -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- Nothing recedes like success. -- Walter Winchell ---------------------------

Date: Fri, 16 Dec 2011 09:43:44 -0800 From: cisin at xenosoft.com To: cctalk at classiccmp.org Subject: SOLUTION (Was: Unix handles file extensions "very poorly"? I have THE definitive solution for the original poster: WRITE A NEW SHELL. It would be the easiest way to get DOS-like filename handling capabilities with Unix. Let's call it "CP.M" (sorry, but '/' creates a few complications) It needs to have built-in commands of TYPE ERASE REN DIR USER and you will also need to write a few programs to go with it, such as PIP.COM and DDT.COM and optionally WS.COM and SC.COM Once it is well established, then you can write ANOTHER one called "COMMAND.COM" It has a longer list of internal commands, including some that are not well known, such as "TRUENAME". It also needs to [MIS]name the bundled programs as "External Commands"! Once THAT is well established, then it will be time to write the definitive Unix GUI, called "WINDOZE" For those who don't like this idea, howzbout porting LDOS? -- Grumpy Ol' Fred cisin at xenosoft.com

I have THE definitive solution for the original poster: WRITE A NEW SHELL. It would be the easiest way to get DOS-like filename handling capabilities with Unix.

On Fri, 16 Dec 2011, Toby Thain wrote: No, no. It's something Unix *can do*. What do YOU mean "have to change the operating system"?? All of the file manipulation crap that you are talking about, such as renaming and wildcards can be done by a program running on Unix. Parsing and DOING "RENAME *.LOG *.OLD" is NOT a big deal.

Well, /strictly/, yes, but since I have never seen or heard of a single UNIX or Linux shell that does what I consider to be the sane or right thing, I think it's fair to say that it's an attribute of the OS as a whole.

I think writing a small program to do what would take a single command on almost any other CLI OS I have ever used illustrates my point rather well...!

Joking aside, I have considered it. I honestly think a decent Win9x/NT-style DOS shell for Linux would help its adoption by Windows techies moving across. The main snag being that C21 Windows techies barely use the CLI at all and are not really skilled in it, whereas 1990s or even 1980s MS techies probably know Unix already. I did start, in the early 1990s, a COMMAND-COM compatible shell for Acorn RISC OS. Its native CLI is deeply odd, as it dates back to the late '70s/early '80s and owes nothing to anything - it was all original. (Examples: directories are called Catalogues and are listed with CAT; their names are separated in paths with dots, rooted at filesystemname::devicenumber:$.; there are no native file extensions but when needed they are simulated with slashes, so an MS-DOS file called C:\DOS\COUNTRY.SYS would be something like dosfs::4:$.DOS.COUNTRY/SYS (allowing for ::0 to ::3 being 4 floppy drives). It was... weird.) I only got as far as DIR, COPY, DEL and TREE and got distracted and moved on. But I'd love a DOS shell for Linux, yes. If I had the skills, I'd try to do it. Partly for the convenience, partly for fun, partly for the sheer joy of outraging traditional old-time Unix-heads. :?) -- 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

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

Joking aside, I have considered it. I honestly think a decent Win9x/NT-style DOS shell for Linux would help its adoption by Windows techies moving across. The main snag being that C21 Windows techies barely use the CLI at all and are not really skilled in it, whereas 1990s or even 1980s MS techies probably know Unix already.

(I am aware of 'file', but that doesn't, to me, do what you're suggesting.)

On Dec 17, 2011 2:15 AM, "John Foust" <jfoust at threedee.com> wrote: suggesting.) Exactly my point. Well, one of them. UNIX /does/ have and use and even depends upon file extensions, and yet, the shell does not really understand them as a separate entity from the file's /name/... & it is poorer than the admittedly far less powerful or capable Microsoft shell at manipulating

files /by extension/ a opposed to /by name/. When I do "ren *.log *.log.old" I am manipulating a /collection/ of files by their shared /extension/ and *not* by their name. No UNIX shell I am aware of can do this. Sure, you can kludge around it with loops or scripts or little Perl programs but that is more effort, more work and I would argue less elegant.

At 07:50 PM 12/16/2011, Toby Thain wrote: Most of the magic and usefulness of 'file' is due to the fact that many commonly used files were in standard formats and did contain fixed magic identifying bytes in their headers. It's metadata inside the file. Extensions put the metadata in the filename, and look at all the tools that assume filename extensions are standard (.sh, .c, .h, .m, .o). - John

How do you think an unix shell is starting an excecutable file and trough wich mechanism it knows what todo with an perl script, an shell script, an C-shell scipt, and different kinds of executable binary formats? It looks in the file for its header and is starting the correct command interpreter for running that file or set up the environment for executing a binary executable.

In unix a shell is doing this,

>> How do you think an unix shell is starting an excecutable file and >> trough wich mechanism it knows what todo with an perl script, an >> shell script, an C-shell scipt, [...]

>> In unix a shell is doing this,

> Actually, in the Unices I know well enough to know where that is > done, it's the kernel that does that, not the shell.

Yes, the shell is doing this trough the system calls.

[...] but the system call is not using any naming conventions of file extensions to do this.

Oh man. Could you please take a look to the print filters in the printing system? This again has nothing todo wit unix as such.

In MS-DOS,

As for print filters, I hvae yet to find any documented option that allows me to tell it whether I want to print a particular piece of text as text or as PostScript code. (Because the content is exactly identical, it cannot even in principle tell on its own.) I haven't run into this problem on more than a half-dozen systems, though; I don't print very much, and even less on systems other than my own. But the details of the issue are not my point; my point is that the content is not always enough to tell.

On 17/12/11 11:13 AM, Holm Tiffe wrote: You are right about that mechanism in shell, for executables. But I was thinking about user files. There's no corresponding mechanism in traditional non-GUI Unix (GUIs usually add one). Yes, that more-or-less happens in those cases (GUIs and executables run from shell). But it *doesn't* happen elsewhere in Unix (e.g. for non-executable files). --T > >This is exactly what the /etc/magic mechanism is doing. > >Regards, > >Holm

Extensions are extensions. All the above is just interpretation. File association is not rocket science (though it's been reinvented too many times). The interesting exception is classic MacOS with its type/creator codes independent of extension (and where extensions were initially absent, though like Unix, supported as part of the file name).

On 12/12/11 5:23 AM, Liam Proven wrote: How does that show that representing extensions as part of a file name string is problematic? Extensions have 2 functions in Unix: ?* aide-memoire for the user including a large set of conventions; ?* (later) compatibility with legacy systems. The representation that Unix uses is effective for these use cases. Can you give an actual example of where Unix handles extensions "very poorly"? (Your faux-DOS command doesn't seem to qualify, as it is neither about Unix (rather, shell), nor a valid use of mv.) In the case of the web, browsers are supposed to pay attention to Content-Type, not sniff by extension. (Yes, I know Apache can be configured to sniff extensions. Again, this works just fine with Unix' representation.) Extensions are extensions. All the above is just interpretation. File association is not rocket science (though it's been reinvented too many times). The interesting exception is classic MacOS with its type/creator codes independent of extension (and where extensions were initially absent, though like Unix, supported as part of the file name).

On Dec 12, 2011, at 9:40 AM, Liam Proven wrote: Well yes, and that's the key, isn't it? ?I think the single most infuriating part of Windows to me is that the system configuration isn't in human-readable text files, it's in inscrutable key/value pairs in a giant global registry. ?It makes it impossible to have any real kind of manual control over the operation of the system unless you are a warlock. ?On Linux and OS X, you can almost always edit a text file somewhere that will be vaguely understandable even if you've never seen it.

On 12 December 2011 15:34, David Riley <fraveydank at gmail.com> wrote: On Linux, yes - if you can find it and then if you can parse the format, as there is no standard at all and it ranges from INI files (as used by Samba) to early pre-Demotic hieroglyphs transcribed in Minoan Linear A and then written in early Sumerian cuneiform (e.g., Sendmail.cf). But OS X? If it's in a file it's probably XML but the chances are it's in netinfo somewhere...

Classic Mac OS had binary preference files, but half the time they could be easily modified with ResEdit, and with very few exceptions, most applications could at least handle having their preference files deleted as basically performing a "factory reset". We had a procedure for that at the Mac Shop. We could almost always

So, since you mentioned it, what DID you to do to do that? :P

I always hotplugged the SCSI cable, though I'm perfectly aware that's a terrible idea (and was then, too).

Apple UGH! Well, I asked.

Apple So, since you mentioned it, what DID you to do to do that? :P

-- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- "I ... I love you!" "Oh noo! I don't!" -- Awful movie, "Ranma 1/2" ---------

I'm not sure what your point is here. that's the intended design.

since when? and why not? Most of us have no problem with this.

you switch back and forth between how the GUI handles files and how the shell handles files,which one are you actually having a problem with? the GUI can easily distinguish between x.foo and x.bar named files.then again, so can the shell. a file extension is not a file "type"extensions as file types is a human fallacy, not a machine limitation.I regularly use files without any type of extension at all, quite easily. also, which shell are we talking about? c-shell? korn shell? bash? zsh?some shells have "extensions" that can differentiate files based on what's after the dot,some refer to the system configurations on what those files are.some don't care what a file is called or what it's "extension" is. the last type is the most correct, what comes after the dot is not truly an "extension"it's just part of the file name, and should be treated as such. the days of the 8 dot 3 file naming and typing conventions are long gone.

> It might outrage or dismay the old hands, but progress often does.

The GUI is for people who don't know how to use a computer.These people should also be forced to use "driverless-cars"

*sigh* OK, here's where Dan and I part company. I use a GUI all the time. Sometimes it's the best/easiest way to do something when I don't want to have to deal with (remembering) the intricacies of a particular feature/function. However, a poorly implemented/thought out GUI is the devil's spawn and can make a CLI a much better alternative. The alternative is also true, you can have CLIs that are so complex that tracking all of the options can be a job in and of itself. Sometimes a GUI wrapper can make those cases much easier to deal with.

It's even more general than that. Many folks have fallen into the Microsoft (FAT) limitation that a file is [3-letter extension format]

In article<F43ABB87-4611-4D9F-81F1-8ACA238D99BB at shiresoft.com>, Guy Sotomayor<ggs at shiresoft.com> writes: Wait, you mean the limitation that is present on RSTS/E, RT-11, RSX-11, TOPS-10, TOPS-20 (and probably a bunch more DEC OSes) and CP/M? In other words: this mental model of a 3-letter file extension was around LONG before Microsoft.

Perhaps it's just me, but I really quite /liked/ the VMS system: name.extension;version. Saved my bacon a few times, did file versioning. Given how cheap disk space is now, I'm saddened it's not made a comeback.

Perhaps it's just me, but I really quite /liked/ the VMS system: name.extension;version. Saved my bacon a few times, did file versioning.

Given how cheap disk space is now, I'm saddened it's not made a comeback.

On 12/12/11 2:43 PM, Liam Proven wrote: It's not as if Unix doesn't offer sophisticated versioning systems - and several flavours of versioning filesystems if you are so inclined. I do not think it need be an overloading of filenames, though. Version control has moved on significantly since 1980...