If you do reset(t, 'myfile ');
it fails due to the trailing space. If one is attempting to use something very close the ISO 7185, then removing the trailing spaces is virtually impossible. Of course, it is easy to do the following:
procedure MyReset(var T: text; F: <some string type>); var i: integer; begin i := 1; while F[i] <> ' ' do i := i + 1; reset(T, F[1..i-1]); end;
Hence I would like to suggest that reset removes trailing spaces, as on my old machine.... (ISO 7185, with very minimal additions).
Brian Wichmann.
Brian Wichmann wrote:
If you do reset(t, 'myfile ');
it fails due to the trailing space. If one is attempting to use something very close the ISO 7185, then removing the trailing spaces is virtually impossible. Of course, it is easy to do the following:
procedure MyReset(var T: text; F: <some string type>); var i: integer; begin i := 1; while F[i] <> ' ' do i := i + 1; reset(T, F[1..i-1]); end;
Hence I would like to suggest that reset removes trailing spaces, as on my old machine.... (ISO 7185, with very minimal additions).
This is absurd.
- a filesystem may allow spaces in file- and pathnames - reset(t, 'myfile ') instead of reset(t, 'myfile') when the filename is 'myfile' is simply an application error - the procedure MyReset doesn't remove trailing spaces, think of 'my file'
Regards,
Adriaan van Os
Adriaan van Os wrote:
Brian Wichmann wrote:
If you do reset(t, 'myfile ');
it fails due to the trailing space. If one is attempting to use something very close the ISO 7185, then removing the trailing spaces is virtually impossible. Of course, it is easy to do the following:
procedure MyReset(var T: text; F: <some string type>); var i: integer; begin i := 1; while F[i] <> ' ' do i := i + 1; reset(T, F[1..i-1]); end;
Hence I would like to suggest that reset removes trailing spaces, as on my old machine.... (ISO 7185, with very minimal additions).
This is absurd.
- a filesystem may allow spaces in file- and pathnames
- reset(t, 'myfile ') instead of reset(t, 'myfile') when the filename
is 'myfile' is simply an application error
- the procedure MyReset doesn't remove trailing spaces, think of 'my
file'
The latter problem is fixable, of course, by counting spaces from the end instead of from the beginning. But otherwise I agree with Adriaan. Many file systems do support file names with trailing spaces, and by trimming spaces we'd make Pascal programs incapable of handling such files (and worse, even doing strange, possibly dangerous, things, if both files, say 'myfile' and 'myfile ' actually exist).
FWIW, I consider the issue of trailing spaces one of the biggest flaws in ISO Pascal (even in 10206 WRT string comparisons, but much more so in 7185). Even if one doesn't "believe" in file names with (trailing) spaces, there are other situations where one might want to have trailing spaces in a string variable, such as when composing an output text out of strings ...
BTW, putting a Chr (0) after the file name happens to solve the problem in GPC (because it passes the file name to the OS via a C-string, which is terminated by the 0 character), but that's more a kludge than anything, and perhaps we should forbid it in future GPC versions (by raising an error if file names etc. contain a 0 character).
I wonder if other ISO 7185 users have come across this problem, and what they do about it.
Brian, did you find this problem in an actual program, or just by trying some corner-cases?
Of course, the 2nd parameter to Reset is non-ISO already, so if one is willing do use this, one might as well use another non-ISO-7185 function, such as Trim (from 10206), which seems designed for solving such issues.
Frank
The problem arose since I have quite a few old Pascal programs on a machine that I prefer not to use. The one in questions makes checks on HTML files within a directory that the links exist. Hence it opens lots of HTML files which have names of different length. Works fine when reset ignores trailing spaces. Trailing spaces are ignored on Unix command lines....
I could recode the programs in Ada 95, but recompiling with gpc seemed a good option.
On 29 Dec 2005, at 16:41, Frank Heckenbach wrote:
Brian, did you find this problem in an actual program, or just by trying some corner-cases?
Being an old hand at ISO 7185, I like to stick to that.
If you take the view that sticking to ISO 7185 is not required, then obviously, Adriaan below is correct...
On 29 Dec 2005, at 08:19, Adriaan van Os wrote:
This is absurd.
- a filesystem may allow spaces in file- and pathnames
- reset(t, 'myfile ') instead of reset(t, 'myfile') when the
filename is 'myfile' is simply an application error
- the procedure MyReset doesn't remove trailing spaces, think of
'my file'
Regards,
Adriaan van Os
Brian.
Brian Wichmann wrote:
The problem arose since I have quite a few old Pascal programs on a machine that I prefer not to use. The one in questions makes checks on HTML files within a directory that the links exist. Hence it opens lots of HTML files which have names of different length. Works fine when reset ignores trailing spaces. Trailing spaces are ignored on Unix command lines....
Actually not. Unix shells strip them, and only so if unquoted. E.g.:
#!/bin/sh
printarg () { echo "The argument is '$1'." }
foo="foo " printarg $foo printarg "$foo"
This script outputs:
The argument is 'foo'. The argument is 'foo '.
In fact, failing to quote shell variables that may contain file names is the major reason why many Unix shell scripts do not work with file names containing spaces. (Which is kind of ironical, sadly, given that the OS itself has supported such file names for several decades while e.g. Dos and earlier versions of Windows didn't.) Whereas scripts that do proper quoting can work with file names containing spaces (trailing or otherwise) just fine.
And files with andd without trailing spaces and otherwise the same file name, can coexist as different files in the same directory:
% ls > "foo" % ls > "foo " % ls -la "foo" -rw------- 1 frank users 4 Dec 29 19:45 foo % ls -la "foo " -rw------- 1 frank users 9 Dec 29 19:45 foo % rm "foo" "foo "
The command line as seen by a Unix program, is an array of strings which can contain any characters except Chr (0).
I could recode the programs in Ada 95, but recompiling with gpc seemed a good option.
Being an old hand at ISO 7185, I like to stick to that.
If you take the view that sticking to ISO 7185 is not required, then obviously, Adriaan below is correct...
I can only repeat myself. ISO 7185 does not have any standard way for a program to specify file names at all, so any such way is already beyond 7185 (Bind is ISO 10206, Assign is UCSD/BP, the 2nd parameter to Reset is an extension of GPC and I think some other compilers). So why not use Trim in this place as well. (I suppose you'd wrap it in a procedure, so it would really be just one place.)
Frank
I agree. Please regard the issue as closed. Brian.
On 29 Dec 2005, at 18:49, Frank Heckenbach wrote:
I can only repeat myself. ISO 7185 does not have any standard way for a program to specify file names at all, so any such way is already beyond 7185 (Bind is ISO 10206, Assign is UCSD/BP, the 2nd parameter to Reset is an extension of GPC and I think some other compilers). So why not use Trim in this place as well. (I suppose you'd wrap it in a procedure, so it would really be just one place.)
Frank
In message 1135882150.5616.401772@goedel.fjf.gnu.de, Frank Heckenbach ih8mj@fjf.gnu.de writes
Assign is UCSD/BP, the 2nd parameter to Reset is an extension of GPC and I think some other compilers).
For the record, I think Assign is BP and the second parameter to reset is certainly UCSD.