12 Dec
2011
12 Dec
'11
9:26 a.m.
On Dec 12, 2011, at 8:07 AM, Dan Gahlinger wrote:
It's even more general than that. Many folks have fallen into the Microsoft (FAT)
limitation that a file is [char]+.[char][char][char] format for a file name. Unix has no
such restrictions. I often create file names flubber.fubar.gorp.baz or sometimes just
blort. About the only thing that the various Unix shells do is that a file name starting
with a '.' are treated special (actually it's 'ls' that does). These
are often looked upon as "hidden" files. Usually because they contain
configuration information for the shell or some other program. Examples: .bashrc, .cshrc,
.emacs, .ssh (for an entire directory), etc.
I agree. Why do I want the shell to impose something on the naming of a file?
Actually it's just by convention and maybe not completely. There's absolutely
*no* reason that I can't name files as: jpeg.pict1, jpeg.pict2, etc. Or even
jpeg-pic1, pic2-jpeg. To find all of the files that I've named with "jpeg",
I could just reference them by "*jpeg*". I don't even have to care what
separator character (if any) was used. About the only convention that's really
imposed by the OS is '.' & '..'.
What I don't understand is the belief that the unix wildcard is difficult.
"*" is powerful and unlike in Microsoft OS's, can appear anywhere in the
name for pattern matching (i.e. *foo*baz* will match any file names that have
"foo" and "baz" appearing in them in that order). Yes, to build more
complex patterns you need to understand regular expressions (but even then regular
expressions aren't that difficult) but I'd argue for anything you'd likely be
doing in a GUI, "*" is sufficient.
*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.
TTFN - Guy
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.
I'm not sure what your point is here. that's the intended design. 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.
since when? and why not? Most of us have no problem with 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.
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.
I'd argue in many cases that what some folks call progress is really a step backwards.
Many powerful concepts were developed early and what some folks call progress is a
"dumbing down" and removal of features because they couldn't be explained to
the masses easily.
I suspect most Mac users barely know their
machines have a shell and
never, ever use it. 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.
The GUI is for
people who don't know how to use a computer.These people should also be forced to use
"driverless-cars"