13 Dec
2011
13 Dec
'11
5:45 p.m.
On 12/12/11 9:51 PM, Liam Proven wrote:
That's good to know. Do you think it is a problem (or at least a
shame) or that it's absolutely fine?
Works for my mother, my wife, and millions of other non-technical OS X
users :)
Well, perhaps not - but it's closer than anything else has ever come.
I haven't lost all hope. Sugar is probably the best Linux-based attempt
I know of. Radical thinking is needed, in my opinion (and yeah, more
radical than OS X, though the latter is highly usable).
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.
I'm still not sure why shell globbing is "significantly more complex"
than DOS globbing (some would aver the contrary).
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:
> 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).
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. 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.
Another issue is that they are not always very portable across
different implementations of Unix, e.g. Linux versus Mac OS X.
Both have bash as the default shell; can't get more portable than that.
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.
Well, except Android, I guess, but it's playing in a different game.
--Toby