Prev: HOW CAN I HACK $5000 FROM PAYPAL WATCH VIDEO.
Next: Fixing stdin inside a redirected loop...
From: Sven Mascheck on 22 Jul 2010 14:46
steven_nospam wrote:
> On Jul 22, 3:01�am, Janis Papanagnou wrote:
>
>> Has the behaviour of "historical versions" changed since then? Which
>> I think was, that everything but / can be used in a file name (and
>> that the names . and .. are treated special), and, that the shell(s)
>> delivered with UNIX use specific characters in her language syntax
>> (like any other text based programming languages do).
>
> When UNIX first appeared on the scene in early 1970's, you could only
> have 14 character filenames, because directory entries were 16-bytes
> long and reserved two bytes for the i-node. By the 1980's they had
> changed the standards to allow for longer names and additional
> characters in file names.

What do you mean with "standards"? Common practice, or something
like predecessors of POSIX or SVID?


> Of course, people who were used to the original standards stayed
> with that standard of not using special characters (including
> control characters), other than perhaps letting their filenames
> get longer.

To avoid confusion: I believe you're talking about habits.
However, Unix itself introduced hardly any but the obvious
limits for filenames, that is, no / or ASCII-NUL.

I am certainly not talking about possible 3rd party apps,
but kernel+filesystem, shell and toolchest.

Examples:

1) 1st edition kernel with 2nd ed userland ('72),

using '<ctrl-c><blank>\<enter>' as filename.
Ctrl-c was not special in the TTY but only unprintable.
(The Thompson shell requires to escpape a nl with \)

# : >' \
'
# ls -l ' \
'
total 0
121 s-rwrw 1 root 0 Jan 1 00:00:00

compare: typing the filename without <ctrl-c>:

# ls -l ' \
'

nonexistent

2) 7th Edition ('79) (with Bourne shell),
using '<ctrl-c><blank><enter>' as filename:

# touch '
> '
# ls|od -b
0000000 003 040 012 012
0000004
--
From: Janis Papanagnou on 22 Jul 2010 17:47
On 22/07/10 17:39, steven_nospam at Yahoo! Canada wrote:
>
> [...]
>
> I've worked with many different people in a variety of UNIX platforms,
> and I've heard plenty complain about the coding in an application they
> are using when a filename suddenly has an unexpected character
> (unexpected by the application) and as a result, avoid using any
> special characters.

You mean C laguage applications or shell applications. Once the file
names (and other arguments) have been passed to the compiled programs
the handling of the shell metacharacters aren't relevant any more -
well.. - modulo using the system() and popen() system calls, which
invoke a shell to execute the commands.

>
> Random? I mean a cleanup utility that deletes files in the wrong place
> (or the wrong file) because a space, question mark, or asterisk was
> added in the name.

Yes, those are known problems when using shells and shell programs.

> Programs or sub-programs that return error codes
> because they treated a filename containing a space incorrectly as two
> or more files rather than one. That sort of thing. Are you telling me
> you've never had a program on a UNIX platform behave in a manner that
> was unexpected because of a character that was used in a filename?
> Perhaps something using find or xargs command?

The problems arise when the shell expands those characters.

>
> Yes, it is possible to simply say "that's not the fault of the person
> naming the file, we should force developers to make their programs
> more robust!". I totally agree with that.

Certainly developers should make their [shell-]programs robust. But
I also think that control characters, white-space, and punctuation
characters should be deprecated in the Unix environment; because it
is often really nasty to make the shell programs handle those names
correct.[*]

[*] Even though quoting variables, occasionally setting IFS, and
using some modern shell's constructs handle 95% of the common cases.

> But that's easy to say if
> you are using a proprietary package and can tell your developers to
> fix it. If you bought a third-party package a few years back, have no
> access to the source code, and you are now out of the support window,
> not quite as easy to address.
>
> Suffice it to say that if you don't account for the special characters
> like spaces, it is possible (and likely) to have problems with saving
> the file. But I think we are off topic a bit, and the OP already said
> he is going to make due with what he has. I'll just keep avoiding
> these characters, and you can keep clicky-clacking. ;-)

Me clicky-clacking?! - certainly not! :-)

Janis

>
>

From: Maxwell Lol on 22 Jul 2010 18:00
>> When UNIX first appeared on the scene in early 1970's, you could only
>> have 14 character filenames, because directory entries were 16-bytes
>> long and reserved two bytes for the i-node. By the 1980's they had
>> changed the standards to allow for longer names and additional
>> characters in file names.
>
> What do you mean with "standards"? Common practice, or something
> like predecessors of POSIX or SVID?

The AT&T Unix (verison 3?) had the short filenames. I think bsd
extended it to 256 characters, and most of the Unix systems used the
BSD filesystem, and inherited the long filenames.

From: Janis Papanagnou on 22 Jul 2010 18:41
On 23/07/10 00:00, Maxwell Lol wrote:
>>> When UNIX first appeared on the scene in early 1970's, you could only
>>> have 14 character filenames, because directory entries were 16-bytes
>>> long and reserved two bytes for the i-node. By the 1980's they had
>>> changed the standards to allow for longer names and additional
>>> characters in file names.
>>
>> What do you mean with "standards"? Common practice, or something
>> like predecessors of POSIX or SVID?
>
> The AT&T Unix (verison 3?) had the short filenames. I think bsd
> extended it to 256 characters, and most of the Unix systems used the
> BSD filesystem, and inherited the long filenames.
>

Interestingly, in Wikipedia I found the term
POSIX "Fully portable filenames"
with the properties... (excerpt)
case-sensitive case-preservation
allowed character set: A�Za�z0�9._-
reserved characters: / null
max. length: 14
hyphen must not be first character


Janis
From: Sven Mascheck on 23 Jul 2010 08:27
Janis Papanagnou <janis_papanagnou(a)hotmail.com> wrote:
> On 23/07/10 00:00, Maxwell Lol wrote:
>> [further attributions snipped?]

>>>> When UNIX first appeared on the scene in early 1970's, you could only
>>>> have 14 character filenames, because directory entries were 16-bytes
>>>> long and reserved two bytes for the i-node. By the 1980's they had
>>>> changed the standards to allow for longer names and additional
>>>> characters in file names.
>>>
>>> What do you mean with "standards"? Common practice, or something
>>> like predecessors of POSIX or SVID?
>>
>> The AT&T Unix (verison 3?) had the short filenames.

I know and didn't mean that limit.
I was talking about allowed characters.
Is it just my misunderstanding?

> Interestingly, in Wikipedia I found the term
> POSIX "Fully portable filenames"

POSIX was released in 1988.
I wonder what "By the 1980's they had changed the
standards" wants to say (see the original context
with "and additional characters").
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: HOW CAN I HACK $5000 FROM PAYPAL WATCH VIDEO.
Next: Fixing stdin inside a redirected loop...