18 Dec
2011
18 Dec
'11
6:46 a.m.
On 17 December 2011 16:26, Holm Tiffe <holm at freibergnet.de> wrote:
Liam Proven wrote:
On Dec 17, 2011 2:15 AM, "John Foust"
<jfoust at threedee.com> wrote:
No, you are really wrong. The above example has absolutly nothing todo with
unix. No one is rejecting you to write a shell that doing things in an
other way. .sh is not neccessary for an shellscript. .c .h .m .o are only
interesting for make or for the ?compiler, which can be an cross compiler
on a entirely different platform. The compiler and make are not neccessarly
parts of the distribution of an unix system.
At 07:50 PM 12/16/2011, Toby Thain wrote:
>(I am aware of 'file', but that doesn't, to me, do what you're
suggesting.)
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).
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.
This is a shell thing and depends of the file expansion with wildcards that
the shell is doing.
Again, nobody rejects that you can write a shell that is doing thinks in an
other way. This has nothing todo with unix. In unix are standard shells
that are following standards how to do this filename expansion. But there
is more than one shell available, many of them, even ascii windowed
versions where you have no chance to give you ren command this way.
Even an NC-clone on unix is a shell to the user. From your discussion with others as well as me, it
seems that you have
a /very/ strict or pure interpretation of what is a
"Unix" attribute
as opposed to what is an attribute of the shell or of some other
program.
This might be arguably correct, in a formal sense, but I do not think
that it is helpful in this case. If you have examples of shells that
behave like Unix shells on non-Unix systems, or of shells that emulate
non-Unix like behaviour on Unix systems, then OK, I will concede the
point.
But otherwise - if the behaviour is due to some part of the Unix
system, be that shell or kernel or compiler or linker or make - and it
always happens on Unix boxes and it does not happen on non-Unix boxes,
then I think it is perfectly fair to say that this is an attribute of
Unix systems.
Sure, it won't happen on a Unix system with no compiler or no shell,
but if all the parts are there, and it does it, then I would say it's
a Unix attribute.
--
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