[NOTE: Yvo posted his message in "povray.bugreports". I posted my reply
here, because it is really off-topic for that group, and I didn't want to
clutter the bug-reports with it...]

smellenbergh wrote in message
<1dl### [at] dialup22leuvenskynetbe>...
>Looks like file names are causing problems on Macintosh, and perhaps
>other platforms too (all platforms allowing spaces as first character in
>file names).
>
>We are aware that this is more an inconvenience than realy a bug but we
>might have a solution.
>
>For example if your input file is ' scene.pov' (notice the space in
>front) POV-Ray is unable to find that file because while parsing the
>option 'Input_File= scene.pov', the space is thrown away.
>
>Why not not change the option parser in a way that options can be
>enclosed like this:
>Input_File=" scene.pov" and Version="3.1" ,......
>
>Or perhaps allowing it only for library paths, input files, output
>files, ..... all options relating to file names.
>If an option is enclosed, the parser should take *all* characters,
>including spaces.
>
>Would it be hard to implement?
>
>Yvo Smellenbergh
>

I don't know about this "bug" and it's fix, I am just curious:

Regardless of if the OS allows a leading space or not: Why would anyone in
his right mind would want to use a leading space in a filename? This looks
to me like inviting problems in more areas than only POV-ray - even if the
OS handles the filenames correctly, humans will *very* easily make mistakes
because it will be so easy to miss the leading space.
Seems just as bad a practice to me as using *several* leading spaces
(imagine, with a proportional font, the fun of "guessing" how many spaces
you have to type to replicate a filename! ;-) or even worse: one or several
*trailing* spaces (and no ".*" fileextension of course, which could spoil
the fun of guessing the number of trailing spaces!)

Well, as said, I am curious. After all, there may be valid reasons... Any
suggestions?

Johannes.

Post a reply to this message

Johannes Hubert <jhu### [at] algonetse> wrote:
: Regardless of if the OS allows a leading space or not: Why would anyone in
: his right mind would want to use a leading space in a filename? This looks
: to me like inviting problems in more areas than only POV-ray - even if the
: OS handles the filenames correctly, humans will *very* easily make mistakes
: because it will be so easy to miss the leading space.
: Seems just as bad a practice to me as using *several* leading spaces
: (imagine, with a proportional font, the fun of "guessing" how many spaces
: you have to type to replicate a filename! ;-) or even worse: one or several
: *trailing* spaces (and no ".*" fileextension of course, which could spoil
: the fun of guessing the number of trailing spaces!)

: Well, as said, I am curious. After all, there may be valid reasons... Any
: suggestions?

  Perhaps he wants to indent the file names properly?-)

  And anyways, you don't have to guess anything if you have a proper shell
which supports file name completion (ok, the completion doesn't work when
you are editing a pov-file... but at least you can look at the number of
spaces :) )

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message

In article <369ceb04.0@news.povray.org> , "Johannes Hubert" <jhu### [at] algonetse>
wrote:

>I don't know about this "bug" and it's fix, I am just curious:
>
>Regardless of if the OS allows a leading space or not: Why would anyone in
>his right mind would want to use a leading space in a filename? This looks
>to me like inviting problems in more areas than only POV-ray - even if the
>OS handles the filenames correctly, humans will *very* easily make mistakes
>because it will be so easy to miss the leading space.
>Seems just as bad a practice to me as using *several* leading spaces
>(imagine, with a proportional font, the fun of "guessing" how many spaces
>you have to type to replicate a filename! ;-) or even worse: one or several
>*trailing* spaces (and no ".*" fileextension of course, which could spoil
>the fun of guessing the number of trailing spaces!)
>
>Well, as said, I am curious. After all, there may be valid reasons... Any
>suggestions?

Just a short technical explaination: Macs don't use pathes to find a unique file. And
spaces are only the tip of the iceberg...Macs allow volumes with the same name...each
volume has an unique ID, so it is no problems...and some users like spaces etc.  For
example spaces in front move (if sorted) the filename to the top.

So the answer should be: As users are allowed to name their files this way
programmers *have to* support it. Actually, this is no problem for Mac OS
applications as long as they don't need path based standard C lib file IO.    And
there is no perfect solution for this :-(


    Thorsten

Post a reply to this message

Thorsten Froehlich wrote in message <369d6197.0@news.povray.org>...

[snip]
>So the answer should be: As users are allowed to name their files this way
>programmers *have to* support it.
[snip]

This is of course true and I never thought anything else. I was more
wondering along the line why OS designers included the possibility of spaces
at the beginning *at all*...

Johannes.

Post a reply to this message

Nieminen Mika wrote in message <369cf48f.0@news.povray.org>...
[snip]
>  And anyways, you don't have to guess anything if you have a proper shell
>which supports file name completion
[snip]

That would have to be a *very* intelligent completion. Figure this:

Two filenames "    abc.txt", "   bcd.txt" (both have 3 leading spaces).
With a proportional font you can see that there are *some* leading spaces
but not how many. So you would have to guess, and completion won't help you
either. Or am I missing some magic feature of completion?

Johannes.

Post a reply to this message

On Thu, 14 Jan 1999 13:03:53 +0100, Johannes Hubert <jhu### [at] algonetse> wrote:
>Nieminen Mika wrote in message <369cf48f.0@news.povray.org>...
>[snip]
>>  And anyways, you don't have to guess anything if you have a proper shell
>>which supports file name completion
>[snip]
>
>That would have to be a *very* intelligent completion. Figure this:
>
>Two filenames "    abc.txt", "   bcd.txt" (both have 3 leading spaces).
                1234           123

If you say so.... :)

Actually, you don't need to know how many spaces.  Since the Mac doesn't
have a command line, you use the mouse to pick the file you want, and the
computer already knows how many spaces there are.  Programs that use command
lines, though, should support quoting.  You have to use quotes on Windows
console-mode programs when using filenames with embedded spaces as well, 
but the shell handles them, which leads me to believe that whatever solution 
is found should be platform-specific.

Post a reply to this message

In article <369df85a.0@news.povray.org> , par### [at] my-dejanewscom (Ron Parker)
wrote:

>If you say so.... :)
>
>Actually, you don't need to know how many spaces.  Since the Mac doesn't
>have a command line, you use the mouse to pick the file you want, and the
>computer already knows how many spaces there are.  Programs that use command
>lines, though, should support quoting.  You have to use quotes on Windows
>console-mode programs when using filenames with embedded spaces as well, 
>but the shell handles them, which leads me to believe that whatever solution 
>is found should be platform-specific.

Well, to the honest, even single or double quotes won't help - the Mac allows nearly
everything as a name.   The solution I would prefer would be a platform independent
syntax option. The must widely used is the URL spec, I think. Details can be found at
http://www.netspace.org/users/dwb/url-guide.html (and in many other places, e.g. the
RFC at http://www.cis.ohio-state.edu/htbin/rfc/rfc1738.html).


    Thorsten

Post a reply to this message

On Thu, 14 Jan 1999 11:02:53 -0600, Thorsten Froehlich 
	<fro### [at] charliecnsiitedu> wrote:
>In article <369df85a.0@news.povray.org> , par### [at] my-dejanewscom (Ron Parker)
>wrote:
>
>>If you say so.... :)
>>
>>Actually, you don't need to know how many spaces.  Since the Mac doesn't
>>have a command line, you use the mouse to pick the file you want, and the
>>computer already knows how many spaces there are.  Programs that use command
>>lines, though, should support quoting.  You have to use quotes on Windows
>>console-mode programs when using filenames with embedded spaces as well, 
>>but the shell handles them, which leads me to believe that whatever solution 
>>is found should be platform-specific.
>
>Well, to the honest, even single or double quotes won't help - the Mac allows nearly
>everything as a name.

I'm pretty sure Unix allows just about anything as well.  (files named -rf, 
anyone?) I think they get around it by escaping important characters.  So a 
file named "test file", including the quotes, would be referenced on the 
command line as "\"test file\"" or something similar.  I suppose this depends 
on your shell, as well.  But on operating systems that support command lines
and have proper shells, this all happens at the shell level, before POV-Ray
even sees it.  The only way it seems there's a problem is if POV-Ray can't 
handle getting "  myfile.pov" (without the quotes) as an argument without
making invalid assumptions (such as that the spaces are redundant) about it.

I guess that brings me to my point: I thought POV just used argv to do its
command-line parsing.  argv is filled in by the shell on OSes with command
lines, so POV should just take what it's given without any further parsing,
at least by default.  I assume (without checking) that the Windows GUI takes 
the arguments that are specified in the Render Options edit box, splits them 
on spaces, and fills in an argv for altmain.  This is too simplistic, and 
probably wrong, but it's a Windows issue rather than a core issue.  I thought 
the Mac UI had a more advanced way to specify these options anyway, so why 
is it a big deal in the first place?  If the Mac UI does allow you to specify 
a command line, it seems like it's the UI's job to parse it into a format 
that's acceptable to altmain.

Unfortunately, I don't have the source code handy at the moment, so I can't
say for sure whether any of these assertions are grounded in fact, but I'm
sure you'll correct me if I'm wrong. :)

Post a reply to this message

Johannes Hubert <jhu### [at] algonetse> wrote:
:>  And anyways, you don't have to guess anything if you have a proper shell
:>which supports file name completion
: [snip]

: That would have to be a *very* intelligent completion. Figure this:

: Two filenames "    abc.txt", "   bcd.txt" (both have 3 leading spaces).
: With a proportional font you can see that there are *some* leading spaces
: but not how many. So you would have to guess, and completion won't help you
: either. Or am I missing some magic feature of completion?

  No problem:
  (pressing tab for file name completion is indicated as <tab>)

talitiainen:~/temp>touch "    abc.txt"
talitiainen:~/temp>ls \ <tab>
talitiainen:~/temp>ls \ \ \ \ abc.txt
    abc.txt

  In UNIX you can specify a literal white space preceding it with \
so just type the first space (ie. "\ ") and press tab for the file completion.
The shell (in this case zsh) makes an intelligent completion, preceding
each special character (such as space, asterisc, question mark, etc) with
a \ so you can easyly see the number of spaces from the number on \'s.
  zsh is even smarter (at least right configured): If there are many file
names with leading spaces, then you can press tab twice and zsh will start
to go through all them until you get the one you wanted (as 4dos does at the
first tab press).
  Now I want to remove that file, so I just make:

talitiainen:~/temp>rm \ <tab>
talitiainen:~/temp>rm \ \ \ \ abc.txt 

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message

Ron Parker <par### [at] my-dejanewscom> wrote:
: I'm pretty sure Unix allows just about anything as well.

  The only thing that is not allowed is putting a / in a file name.

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message