12 Dec
2011
12 Dec
'11
6:51 p.m.
On 13 December 2011 00:25, Toby Thain <toby at telegraphics.com.au> wrote:
There are, yes, but they are, IME, *significantly* more complex to use
(and therefore to learn to use) than DOS' or CMD.EXE's.
Another issue is that they are not always very portable across
different implementations of Unix, e.g. Linux versus Mac OS X.
That's good to know. Do you think it is a problem (or at least a
shame) or that it's absolutely fine?
Well, perhaps not - but it's closer than anything else has ever come.
Well, except Android, I guess, but it's playing in a different game.
--
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
On 12/12/11 9:40 AM, Liam Proven wrote:
Now let's not get carried away here! ;?)
On 12 December 2011 14:08, Toby Thain<toby at
telegraphics.com.au> ?wrote:
And this is wonderful. Do you really want filenames with multiple fields?!
Can you then imagine how you could use the powerful tools available on such
names, with equal ease? Such needless complication would be much harder to
implement and learn. Next you'll be saying we should write and store
documents in XML! ;-) On 12/12/11 5:23 AM, Liam Proven wrote:
They work inasmuch as you can give files a name with a dot in it and
some text after the dot and it's a valid name. On 12 December 2011 04:17, Alexander
Schreiber<als at thangorodrim.de>
?wrote:
> On Sat, Dec 10, 2011 at 04:59:48PM +0000, Liam Proven wrote:
>> On 8 December 2011 21:03, Dave McGuire<mcguire at neurotica.com>
>> ?wrote:
>>> On 12/07/2011 08:14 PM, Liam Proven wrote:
>>>>
>>>> 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.
>>>
>>> ?UNIX shell wildcards? ?A question mark matches any single character,
>>> an
>>> asterisk matches any number of any characters. ?What's so tough about
>>> that?
>>
>> 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.
>
> Wrong tool.
>
> If you want to do the above, use mmv:
> mmv "*.log" "#1.old"
>
>> In general, because file extensions are a sort of grafted-on
>> afterthought on Unix, I find it handles them very poorly, whereas they
>
> Unix actually doesn't give a damn about so-called file extensions. As
> far as Unix cares, ".log", ".png", ".whatever" is just
a part of the
> filename. ...
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.
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.)
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.
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). When I'm
saying it handles it poorly is that, from the POV of the
shell, it's just a filename, it contains no information. Files called
something-dot-foo can't readily be handled separately from
something-dot-bar.
I think this thread started with mentions of the endless Unix-based
facilities for doing this. In most modern
Unix GUIs, you can sort by file type, grab all the
JPEGs and move them to another folder, say - or even all the image
files, all the JPEGs and PNGs and BMPs or whetever. In the shell,
that's harder, requiring a serious understanding of the Unix wildcard
mechanisms and possibly, as illustrated by some of the replies to my
earlier post about log files, writing a short script.
But that's OK. As it is on the Mac, use of the CLI is on the wane in
modern Linux, too. I suspect many happy Ubuntu users can get by with
never using the Terminal, except occasionally to copy-and-paste some
command in from the web or from a support tech. And that's just fine
and I think that the progression will continue.
It might outrage or dismay the old hands, but progress often does.
I suspect most Mac users barely know their machines have a shell and
never, ever use it.
That would be accurate, in my experience. If Ubuntu gets to that point as well, that will
be
just fine - so long as people can do what they want and need to do.
I think Linux needs to get to that point; I've argued so for at least 10
years. But I am not sure Ubuntu will be the vehicle.