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

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

>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?

Well, there is no *clean* way to pass options to POV-Ray except through the command
line in some way when using altmain. What we do is rather simple: All options are
taken from the dialog, then stored in a resource which is (Mac-like) in the resource
fork of the file (the data fork contains the text file part). When building the
command line we use this resource's data and allocate a string with the proper
argument. After altmain we free this memory. The (currently) only other way would be
to directly manipulate "internal" data structures.

The way we use is to check if a filename etc. uses with characters the core code
cannot handle. Then we warn the user.

>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.

No it does not offer a command line, but it offers full INI file support of course...

>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. :)

I think (I am not sure) that the command line parser will even take several arguments
in one string, so the UI does not need to split it.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: Tho### [at] csicom
e-mail: fro### [at] charliecnsiitedu

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://www.povray.org

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? 
[..]
Thorsten Froehlich <fro### [at] charliecnsiitedu> wrote:

> 
> 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 :-(

As Thorsten said, there are all kinds of reasons for using a leading
space in a file name or volume name. 

We recently got a bug report [about our unofficial version] from a new
(I guess) POV-Ray user.
POV-Ray kept on complaning that the file 'xxx' could not be found. And
looking at this message you keep asking yourself why, why,.. if your eye
doesn't catch it you can look for a long time!
In this case the reason for the space was probably just because 
' Macintosh HD ' looks nicer on the desktop then 'Macintosh HD'.

I think that the space character is one of the most used ones in file
names on a Mac and especially this character is not handled right by
POV-Ray.

Anyway, the official version not only has a problem when the file name
has a leading space but also if the library paths have them. 
Our version only doesn't like a leading space in a volume name, but the
problem remains.

POV-Ray still attracts new users (yeh!) every day and those users should
be able to render the examples, even if there volume(s) have a leading
space.
And if I remember well, there have been some bug reports concerning this
to the Mac-Pov-Team-dudes in the past. So it *did* happen and it *still*
does happen!

Perhaps a warning in the message window is required if a leading space
is detected instead of 'could not find file' on platforms where it
matters.

Yvo Smellenbergh

-- e-mail:sme### [at] skynetbe

http://users.skynet.be/smellenbergh

Post a reply to this message

Nieminen Mika wrote in message <369e340b.0@news.povray.org>...
>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

I think you missed my point: I wrote that there are *two* files, called "
abc.txt" and "   bcd.txt".
So when you enter

talitiainen:~/temp>ls \ <tab>

the shell would have to guess which one you mean. As I understand
completion, nothing happens when you press <tab> as long as it is not clear
from the uncomplete part, which of several possible options is meant. As
long as it is not clear you need to enter further charaters, until you
entered a "startstring" that is unique. Then you can press <tab> for
completion. Well, and this unique startstring would be hard to guess since
both filenames start with 3 spaces, but you only know *that* they start with
spaces, not with how many... (Note my other condition: Usage of a
proportinal font, which would make "counting" spaces hard.)

Johannes.

Post a reply to this message

Have to add a thing here..

in Sweden, and also is allowed by windoze 95... but, POV went off on those too...

//Spider

Johannes Hubert wrote:
> 
> [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:
: the shell would have to guess which one you mean. As I understand
: completion, nothing happens when you press <tab> as long as it is not clear
: from the uncomplete part, which of several possible options is meant.

  I quote myself:

>   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).

-- 
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

Aarrgh!
Guess I should read postings more carefully... :-)

Johannes.

Post a reply to this message