This will probably explode into a heated debate, but...

For non-scripting purposes, is there any general rule/preference for quoting filenames with spaces,
i.e. using double-quotes (") or single quotes (')?

Or is this a matter of personal choice.

On 2016-12-17, gargoyle60 <gargoyle60@example.invalid> wrote:
> This will probably explode into a heated debate, but...
>
> For non-scripting purposes, is there any general rule/preference for quoting filenames with spaces,
> i.e. using double-quotes (") or single quotes (')?
>
> Or is this a matter of personal choice.

Double quotes will allow globs in the filename, single quotes will
transmit the globs verbatim

ls "This is*"
will list  
This is a big file
while 
ls 'This is*' will list the file with the literal name 
This is*
So, not preferences but different uses.

William Unruh <unruh@invalid.ca> writes:
> gargoyle60 <gargoyle60@example.invalid> wrote:
>> This will probably explode into a heated debate, but...
>>
>> For non-scripting purposes, is there any general rule/preference for
>> quoting filenames with spaces,
>> i.e. using double-quotes (") or single quotes (')?
>>
>> Or is this a matter of personal choice.
>
> Double quotes will allow globs in the filename, single quotes will
> transmit the globs verbatim
>
> ls "This is*"
> will list  
> This is a big file

No, it won’t.

-- 
http://www.greenend.org.uk/rjk/

At Sat, 17 Dec 2016 11:55:47 +0000 gargoyle60 <gargoyle60@example.invalid> wrote:

> 
> This will probably explode into a heated debate, but...
> 
> For non-scripting purposes, is there any general rule/preference for quoting filenames with spaces,
> i.e. using double-quotes (") or single quotes (')?

Double-quotes (") are problematical in that what is between them is
"evaluated" (eg $ substitution takes place, etc.). Note that there is also
backslash quoting available. Note further: with scp, you have to quote the
spaces *twice*: once for the local shell and once for the remote shell:

scp mail.deepsoft.com:'Mail/Attachments/Stupid\ Dumb\ Ass\ Filename.pdf' /local/path/
                              

> 
> Or is this a matter of personal choice.
>                                                    

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                                                               

At Sat, 17 Dec 2016 13:51:58 +0000 Richard Kettlewell <invalid@invalid.invalid> wrote:

> 
> William Unruh <unruh@invalid.ca> writes:
> > gargoyle60 <gargoyle60@example.invalid> wrote:
> >> This will probably explode into a heated debate, but...
> >>
> >> For non-scripting purposes, is there any general rule/preference for
> >> quoting filenames with spaces,
> >> i.e. using double-quotes (") or single quotes (')?
> >>
> >> Or is this a matter of personal choice.
> >
> > Double quotes will allow globs in the filename, single quotes will
> > transmit the globs verbatim
> >
> > ls "This is*"
> > will list  
> > This is a big file
> 
> No, it won't.

Depends on the shell and/or if the glob matches anything.  Single quotes 
and/or backslashes are *always* 'safe' for all cases.

> 

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                      

Robert Heller <heller@deepsoft.com> writes:
> Richard Kettlewell <invalid@invalid.invalid> wrote:
>> William Unruh <unruh@invalid.ca> writes:
>>> gargoyle60 <gargoyle60@example.invalid> wrote:

>>>> This will probably explode into a heated debate, but...
>>>>
>>>> For non-scripting purposes, is there any general rule/preference for
>>>> quoting filenames with spaces,
>>>> i.e. using double-quotes (") or single quotes (')?
>>>>
>>>> Or is this a matter of personal choice.
>>>
>>> Double quotes will allow globs in the filename, single quotes will
>>> transmit the globs verbatim
>>>
>>> ls "This is*"
>>> will list  
>>> This is a big file
>> 
>> No, it won't.
>
> Depends on the shell and/or if the glob matches anything.  Single
> quotes and/or backslashes are *always* 'safe' for all cases.

In which shell will a glob pattern inside double quotes be expanded?

-- 
http://www.greenend.org.uk/rjk/

On 2016-12-17 15:34, Robert Heller wrote:
> At Sat, 17 Dec 2016 13:51:58 +0000 Richard Kettlewell <invalid@invalid.invalid> wrote:
> 
>>
>> William Unruh <unruh@invalid.ca> writes:
>>> gargoyle60 <gargoyle60@example.invalid> wrote:
>>>> This will probably explode into a heated debate, but...
>>>>
>>>> For non-scripting purposes, is there any general rule/preference for
>>>> quoting filenames with spaces,
>>>> i.e. using double-quotes (") or single quotes (')?
>>>>
>>>> Or is this a matter of personal choice.
>>>
>>> Double quotes will allow globs in the filename, single quotes will
>>> transmit the globs verbatim
>>>
>>> ls "This is*"
>>> will list  
>>> This is a big file
>>
>> No, it won't.
> 
> Depends on the shell and/or if the glob matches anything.  Single quotes 
> and/or backslashes are *always* 'safe' for all cases.

I understand that the OP is not interested in shells. He said "for
non-scripting purposes", so how to write filenames with spaces on the
command line is not of his interest.

-- 
Cheers,
       Carlos E.R.

At Sat, 17 Dec 2016 17:31:23 +0100 "Carlos E. R." <robin_listas@invalid.es> wrote:

> 
> On 2016-12-17 15:34, Robert Heller wrote:
> > At Sat, 17 Dec 2016 13:51:58 +0000 Richard Kettlewell <invalid@invalid.invalid> wrote:
> > 
> >>
> >> William Unruh <unruh@invalid.ca> writes:
> >>> gargoyle60 <gargoyle60@example.invalid> wrote:
> >>>> This will probably explode into a heated debate, but...
> >>>>
> >>>> For non-scripting purposes, is there any general rule/preference for
> >>>> quoting filenames with spaces,
> >>>> i.e. using double-quotes (") or single quotes (')?
> >>>>
> >>>> Or is this a matter of personal choice.
> >>>
> >>> Double quotes will allow globs in the filename, single quotes will
> >>> transmit the globs verbatim
> >>>
> >>> ls "This is*"
> >>> will list  
> >>> This is a big file
> >>
> >> No, it won't.
> > 
> > Depends on the shell and/or if the glob matches anything.  Single quotes 
> > and/or backslashes are *always* 'safe' for all cases.
> 
> I understand that the OP is not interested in shells. He said "for
> non-scripting purposes", so how to write filenames with spaces on the
> command line is not of his interest.

That was not clear.  If he is talking about in something like a C program, 
there isn't any need to "quote" filenames beyond C's own quoting:

    FILE *x = fopen("Stupid Dumb Ass Filename.pdf","r");
    
I believe he was talking about a shell situation, just not a script file, but 
specificly at the interactive "shell" prompt, where one might want to do 
something like:

mv "Stupid Dumb Ass Filename.pdf" Proper_Filename.pdf

and wanted to know whether there is a preference for

mv 'Stupid Dumb Ass Filename.pdf' Proper_Filename.pdf

or even

mv Stupid\ Dumb\ Ass\ Filename.pdf Proper_Filename.pdf

I guess *I* am adverse to double quotes, mostly because in many situations
stuff can happen in double quoted strings, but that with single quotes one is
certain that nothing inside will be processed in any way. In both bash and
tcsh, a string in double quotes that contains a dollar sign ($) will get
variable expansion as well as other expansions:

sauron.deepsoft.com% echo "This is my $HOME"
This is my /home/heller
sauron.deepsoft.com% echo 'This is my $HOME'
This is my $HOME
sauron.deepsoft.com% echo "This is my `pwd`"
This is my /home/heller
sauron.deepsoft.com% echo 'This is my `pwd`'
This is my `pwd`

(This is with /bin/tcsh)

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
         

gargoyle60 <gargoyle60@example.invalid> wrote:
> This will probably explode into a heated debate, but...
> 
> For non-scripting purposes,

Please explain what you mean by "non-scripting purposes". [1]

> is there any general rule/preference for quoting filenames with spaces,
> i.e. using double-quotes (") or single quotes (')?
> 
> Or is this a matter of personal choice.

Until you answer what you mean by "non-scripting purposes" any answer
anyone gives will likely not be to your real question.



[1] I see at least two possibilities for your meaning (and your real
  question may be to a third I don't yet see):
  1) in a document context
  2) in a compiled language (C, Go, Rust, etc.) (which are not
     considered "scripting" languages)

At Sat, 17 Dec 2016 19:24:31 -0000 (UTC) Rich <rich@example.invalid> wrote:

> 
> gargoyle60 <gargoyle60@example.invalid> wrote:
> > This will probably explode into a heated debate, but...
> > 
> > For non-scripting purposes,
> 
> Please explain what you mean by "non-scripting purposes". [1]

*My* guess is in an interactive shell -- eg. xterm or something like that,
using "traditional" UNIX CLI tools (mv, cp, rm, etc.) to deal with files
created in a point-and-click environment, where spaces and other [shell] meta
characters might have been used with abandon.

> 
> > is there any general rule/preference for quoting filenames with spaces,
> > i.e. using double-quotes (") or single quotes (')?
> > 
> > Or is this a matter of personal choice.
> 
> Until you answer what you mean by "non-scripting purposes" any answer
> anyone gives will likely not be to your real question.
> 
> 
> 
> [1] I see at least two possibilities for your meaning (and your real
>   question may be to a third I don't yet see):
>   1) in a document context
>   2) in a compiled language (C, Go, Rust, etc.) (which are not
>      considered "scripting" languages)
> 
>                                 

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                                                        

On Sat, 17 Dec 2016 11:51:09 -0600, Robert Heller <heller@deepsoft.com> wrote:

>I believe he was talking about a shell situation, just not a script file, but 
>specificly at the interactive "shell" prompt, where one might want to do 
>something like:
>
>mv "Stupid Dumb Ass Filename.pdf" Proper_Filename.pdf


Correct!

gargoyle60 <gargoyle60@example.invalid> wrote:
> On Sat, 17 Dec 2016 11:51:09 -0600, Robert Heller <heller@deepsoft.com> wrote:
> 
>>I believe he was talking about a shell situation, just not a script file, but 
>>specificly at the interactive "shell" prompt, where one might want to do 
>>something like:
>>
>>mv "Stupid Dumb Ass Filename.pdf" Proper_Filename.pdf
> 
> 
> Correct!

In which case it is not a "preference" as implied by the initial
question at all, but a *deterministic* choice.

All three methods have different meanings, and which "quote" to choose
at any given instance is determined by what the typist wishes to have
happen to the characters in the resulting input string:

man bash (from the QUOTING section):

       Each  of  the  metacharacters listed above under DEFINITIONS has
       special meaning to the shell and must be quoted if it is to
       represent itself.

       When the command history expansion facilities are being used
       (see HISTORY EXPANSION below), the history expansion character,
       usually !, must be quoted to prevent history expansion.

       There are three quoting mechanisms: the escape character, single
       quotes, and double quotes.

       A non-quoted backslash (\) is the escape character.  It
       preserves the literal value of the next character that follows,
       with the exception of <newline>.  If a \<newline> pair appears,
       and the backslash is not itself quoted, the \<newline> is
       treated as a line continuation (that is, it is removed from the
       input stream and effectively ignored).

       Enclosing characters in single quotes preserves the literal
       value of each character within the quotes.  A single quote may
       not occur between single quotes, even when preceded by a
       backslash.

       Enclosing characters in double quotes preserves the literal
       value of all characters within the quotes, with the exception of
       $, `, \, and, when history expansion is enabled, !.  The
       characters $ and ` retain their special meaning within double
       quotes.  The backslash retains its special meaning only when
       followed by one of the following characters: $, `, ", \, or
       <newline>.  A double quote may be quoted within double quotes by
       preceding it with a backslash.  If enabled, history expansion
       will be performed unless an !  appearing in double quotes is
       escaped using a backslash.  The backslash preceding the !  is
       not removed.

So, the answer is: pick the quote that performs the function they want
performed on the string.

Do they want all characters preserved literally, and there are no
single quotes in the filename?: if yes then pick single quote.

Do they want $ ` \ and ! to have their special meanings?: then pick
double quote.

Is there a single quote in the name?: then pick the backslash quote
method.

But it is not a "preference" in that one can not pick just one method
and have it work in every single instance, which is what the OP's
original question implied.  Single quotes are _almost_ a works in every
instance choice, except that they disallow containing single quotes in
all cases.  Which means single quotes work, until a name itself
containing a single quote appears, then single quoting fails.

On 2016-12-17, gargoyle60 <gargoyle60@example.invalid> wrote:
> For non-scripting purposes, is there any general rule/preference for quoting filenames with spaces,
> i.e. using double-quotes (") or single quotes (')?

Too bad there's not a general preference for naming files without using
spaces.
-- 
                                 Chick Tower

For e-mail:  colm DOT sent DOT towerboy AT xoxy DOT net

At Sun, 18 Dec 2016 18:50:21 -0000 (UTC) Chick Tower <c.tower@deadspam.com> wrote:

> 
> On 2016-12-17, gargoyle60 <gargoyle60@example.invalid> wrote:
> > For non-scripting purposes, is there any general rule/preference for quoting filenames with spaces,
> > i.e. using double-quotes (") or single quotes (')?
> 
> Too bad there's not a general preference for naming files without using
> spaces.

Blame Apple, who basicly "invented" file names with spaces. (M$ was just 
copycatting MacOS.)

There are several options for CLI-friendly file names with multiple 'words':

CamelCase.pdf
Dashes-between-words.c
Underscores_Also_Work_Well.f
And.So.Do.dots.p

I sort of use both Camel Case and Underscores, with dashes sometimes.  I 
generally limit filenames to only having one dot (sometimes two when dealing 
with compressed files -- eg foo.tar.gz).


-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                       

Chick Tower <c.tower@deadspam.com> wrote:
>On 2016-12-17, gargoyle60 <gargoyle60@example.invalid> wrote:
>> For non-scripting purposes, is there any general rule/preference for quoting filenames with spaces,
>> i.e. using double-quotes (") or single quotes (')?
>
>Too bad there's not a general preference for naming files without using
>spaces.

But there is exactly that!  Or... amoungt programmers
who program for programmers there is that perference.
Then along came programmers programming for
non-programmers who would not know the difference or
difficulties, and would therefore see the use of
underscores in place of spaces as an indication of
insanity...

So we have those who read source code and think spaces
in file names is insanity.  And we have those who read
onlhy English and think that a lack of spaces in file
names is insanity.

Pick your poison.

-- 
Floyd L. Davidson                         http://www.apaflo.com/
Utqiagvik (Barrow, Alaska)                      floyd@apaflo.com

On Sunday 18 December 2016 20:13, Robert Heller conveyed the following 
to comp.os.linux.misc...

> There are several options for CLI-friendly file names with multiple
> 'words':
> 
> CamelCase.pdf
> Dashes-between-words.c
> Underscores_Also_Work_Well.f
> And.So.Do.dots.p
> 
> I sort of use both Camel Case and Underscores, with dashes sometimes. 
> I generally limit filenames to only having one dot (sometimes two when
> dealing with compressed files -- eg foo.tar.gz).

Same here.  I prefer underscores for files of my own creation, and I 
generally stick with only one dot, except for the cited example of 
compressed tarballs. ;)

-- 
= Aragorn =

At Sun, 18 Dec 2016 22:13:40 +0100 Aragorn <thorongil@telenet.be> wrote:

> 
> On Sunday 18 December 2016 20:13, Robert Heller conveyed the following 
> to comp.os.linux.misc...
> 
> > There are several options for CLI-friendly file names with multiple
> > 'words':
> > 
> > CamelCase.pdf
> > Dashes-between-words.c
> > Underscores_Also_Work_Well.f
> > And.So.Do.dots.p
> > 
> > I sort of use both Camel Case and Underscores, with dashes sometimes. 
> > I generally limit filenames to only having one dot (sometimes two when
> > dealing with compressed files -- eg foo.tar.gz).
> 
> Same here.  I prefer underscores for files of my own creation, and I 
> generally stick with only one dot, except for the cited example of 
> compressed tarballs. ;)

And sometimes *other* compressed files that might happen along.  And (rarely) 
other sorts of "stacked" extensions.  That is, dots are reserved for 
"extensions", and files *generally* only have one extension, but there are 
special cases where a file has a stacked set of extensions (most commonly due 
to compression).

> 

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                                                                              

On 2016-12-18, Chick Tower <c.tower@deadspam.com> wrote:
> On 2016-12-17, gargoyle60 <gargoyle60@example.invalid> wrote:
>> For non-scripting purposes, is there any general rule/preference for quoting filenames with spaces,
>> i.e. using double-quotes (") or single quotes (')?
>
> Too bad there's not a general preference for naming files without using
> spaces.

There is. But a few programs, often developed on Windows or Mac, where
filenames with spaces are common, violate that general prference.

floyd@apaflo.com (Floyd L. Davidson) writes:
> Chick Tower <c.tower@deadspam.com> wrote:
>> Too bad there's not a general preference for naming files without
>> using spaces.
>
> But there is exactly that!  Or... amoungt programmers
> who program for programmers there is that perference.
> Then along came programmers programming for
> non-programmers who would not know the difference or
> difficulties, and would therefore see the use of
> underscores in place of spaces as an indication of
> insanity...
>
> So we have those who read source code and think spaces
> in file names is insanity.  And we have those who read
> onlhy English and think that a lack of spaces in file
> names is insanity.

I have been reading and writing computer programs both for a living and
as a hobby for decades now, and my view is that when humans want to use
spaces (or anything else) in filenames, computers should support
that. As such designs that make it inconvenient to do so are bad ones.

-- 
http://www.greenend.org.uk/rjk/

On Sat, 17 Dec 2016 11:55:47 +0000, gargoyle60 <gargoyle60@example.invalid> wrote:

Thanks for all the answers.

[Within Windows] I am copying filenames with spaces from an old Windows partition and converting the
spaces to underscores (my own preference from my old UNIX days), but couldn't remember if there was
a general preference for using double-quotes or single quotes for the original filenames with
spaces. 
My personal preference is to use single but I thought is worthwhile to get a general consensus, if
any.

Having said that, I have run into problems with using WZUNZIP.EXE under WinXP with single quotes
with some filenames, so for unzipping operation prior to copying I have had to use double quotes as
the exception.

On 18/12/16 21:13, Robert Heller wrote:
> Blame Apple, who basicly "invented" file names with spaces. (M$ was just
> copycatting MacOS.)

surely Unix had spaced filenames before either?

On 19/12/16 11:23, gargoyle60 wrote:
> On Sat, 17 Dec 2016 11:55:47 +0000, gargoyle60 <gargoyle60@example.invalid> wrote:
>
> Thanks for all the answers.
>
> [Within Windows] I am copying filenames with spaces from an old Windows partition and converting the
> spaces to underscores (my own preference from my old UNIX days), but couldn't remember if there was
> a general preference for using double-quotes or single quotes for the original filenames with
> spaces.
> My personal preference is to use single but I thought is worthwhile to get a general consensus, if
> any.
>
> Having said that, I have run into problems with using WZUNZIP.EXE under WinXP with single quotes
> with some filenames, so for unzipping operation prior to copying I have had to use double quotes as
> the exception.
>
I discovered that my minidlna player couldn't handle multiple periods 
and OS/X REALlY didn't like colons. I don't suppose windows does either.

All were happy with spaces. Linux was happy with ANYTHING.

William Unruh <unruh@invalid.ca> Wrote in message:
> On 2016-12-17, gargoyle60 <gargoyle60@example.invalid> wrote:
>> This will probably explode into a heated debate, but...
>>
>> For non-scripting purposes, is there any general rule/preference for quoting filenames with spaces,
>> i.e. using double-quotes (") or single quotes (')?
>>
>> Or is this a matter of personal choice.
> 
> Double quotes will allow globs in the filename, single quotes will
> transmit the globs verbatim
> 
> ls "This is*"
> will list  
> This is a big file
> while 
> ls 'This is*' will list the file with the literal name 
> This is*
> So, not preferences but different uses.
> 
> 

If the OP means a file with a filename that includes spaces, not a
 glob,
I believe that in Bash, either type of quote will work.
The Linux Cookbook says that when quoting an expression with an 
apostrophe, use double quotes.  When quoting an expression that
already contains double quotes, use single quotes.  It is my 
understanding that neither of those can be a valid filename.

Doug.
-- 

dlbendigo  <laidlaws@hotkey.net.au> writes:
> If the OP means a file with a filename that includes spaces, not a
> glob,
> I believe that in Bash, either type of quote will work.
> The Linux Cookbook says that when quoting an expression with an 
> apostrophe, use double quotes.  When quoting an expression that
> already contains double quotes, use single quotes.  It is my 
> understanding that neither of those can be a valid filename.

Either type of quote may appear in a filename.

    $ ls -l
    total 0
    -rw-rw-r-- 1 rjk rjk 0 Dec 19 16:29 '
    -rw-rw-r-- 1 rjk rjk 0 Dec 19 16:31 '"
    -rw-rw-r-- 1 rjk rjk 0 Dec 19 16:29 "

-- 
http://www.greenend.org.uk/rjk/

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

dlbendigo [2016-12-20 03:18:03+11] wrote:

> The Linux Cookbook says that when quoting an expression with an
> apostrophe, use double quotes. When quoting an expression that already
> contains double quotes, use single quotes. It is my understanding that
> neither of those can be a valid filename.

Only bytes $00 (NUL) and $2F (/) are illegal in filenames. Any other
byte values are allowed. So effectively in UTF-8 encoding we can have
any Unicode characters in filenames except those two (U+0000 and
U+002F).

=2D-=20
/// Teemu Likonen   - .-..   <https://github.com/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJYWBIbAAoJEJM6NQQefq1RxKkH/ibhdQDdnAdo8N1LbuyB8KuX
MtOP1cMt/oK+/rFtIlxWFGl7JbtRnI89DotCKfn7BMqne8EA4sFCY8paUMb41xfK
lkhYjfRf9oRTJyQ+wCjzZGh0dnZUP7h47XZICg0/sHhe3EwGB9XqwgqUWHyZDuRy
G6GLbBle8YKSXM0/SaoRSmWhutbYsikGt89VR1J+OKyOAfJuUaSwpMXEOBRKzeK7
f3xbT0eZXS57RqL2TYVG8vjuhYbOfxAtIG5ZX2hQw+UPeRFrh5NH7Tm2MDv57B/m
klEx9U8d/7tXLGtBvLkQooRVCkt/QzNNd9PjR4Rh47rZ7fpBKa17b7TIGP/N91E=
=kAaU
-----END PGP SIGNATURE-----
--=-=-=--

dlbendigo <laidlaws@hotkey.net.au> wrote:
> The Linux Cookbook says that when quoting an expression with an 
> apostrophe, use double quotes.  When quoting an expression that
> already contains double quotes, use single quotes.  It is my 
> understanding that neither of those can be a valid filename.

Then your understanding is incorrect (at least when it comes to a Linux
system and a Linux filesystem):

   $ touch single\'quote
   $ touch double\"quote
   $ ls 
   double"quote  single'quote

Linux inherits the Unix filename semantics.  Unix disallows only two
characters in a filename:

  1) an ASCII null character (0) (because it is already used internally
     by the C libraries to mark the end of a string)

  2) an ASCII forward slash character (/) (because it is used to
     delimit directory names in paths)

Any other character _may_ appear in a Linux filename.  Even
non-printing characters.  

On 19/12/16 19:06, Rich wrote:
> dlbendigo <laidlaws@hotkey.net.au> wrote:
>> The Linux Cookbook says that when quoting an expression with an
>> apostrophe, use double quotes.  When quoting an expression that
>> already contains double quotes, use single quotes.  It is my
>> understanding that neither of those can be a valid filename.
>
> Then your understanding is incorrect (at least when it comes to a Linux
> system and a Linux filesystem):
>
>    $ touch single\'quote
>    $ touch double\"quote
>    $ ls
>    double"quote  single'quote
>
> Linux inherits the Unix filename semantics.  Unix disallows only two
> characters in a filename:
>
>   1) an ASCII null character (0) (because it is already used internally
>      by the C libraries to mark the end of a string)
>
>   2) an ASCII forward slash character (/) (because it is used to
>      delimit directory names in paths)
>
> Any other character _may_ appear in a Linux filename.  Even
> non-printing characters.
>
the game used to be to create 'undeleteble' files in other peoples home 
dirs...using special characters that didn't appear on screen.

On 2016-12-19, Richard Kettlewell <invalid@invalid.invalid> wrote:
> floyd@apaflo.com (Floyd L. Davidson) writes:
>> Chick Tower <c.tower@deadspam.com> wrote:
>>> Too bad there's not a general preference for naming files without
>>> using spaces.
>>
>> But there is exactly that!  Or... amoungt programmers
>> who program for programmers there is that perference.
>> Then along came programmers programming for
>> non-programmers who would not know the difference or
>> difficulties, and would therefore see the use of
>> underscores in place of spaces as an indication of
>> insanity...
>>
>> So we have those who read source code and think spaces
>> in file names is insanity.  And we have those who read
>> onlhy English and think that a lack of spaces in file
>> names is insanity.
>
> I have been reading and writing computer programs both for a living and
> as a hobby for decades now, and my view is that when humans want to use
> spaces (or anything else) in filenames, computers should support
> that. As such designs that make it inconvenient to do so are bad ones.

????? Human useage is often highly ambiguous, which is why understanding
natural language is so hard for computers. 
So if they want to put carriage returns into their filename this would
be OK with you? And is
apple pear cinammon 
one name or three?  How is the computer to know which it is?



>

On 19/12/16 19:24, William Unruh wrote:
> On 2016-12-19, Richard Kettlewell <invalid@invalid.invalid> wrote:
>> floyd@apaflo.com (Floyd L. Davidson) writes:
>>> Chick Tower <c.tower@deadspam.com> wrote:
>>>> Too bad there's not a general preference for naming files without
>>>> using spaces.
>>>
>>> But there is exactly that!  Or... amoungt programmers
>>> who program for programmers there is that perference.
>>> Then along came programmers programming for
>>> non-programmers who would not know the difference or
>>> difficulties, and would therefore see the use of
>>> underscores in place of spaces as an indication of
>>> insanity...
>>>
>>> So we have those who read source code and think spaces
>>> in file names is insanity.  And we have those who read
>>> onlhy English and think that a lack of spaces in file
>>> names is insanity.
>>
>> I have been reading and writing computer programs both for a living and
>> as a hobby for decades now, and my view is that when humans want to use
>> spaces (or anything else) in filenames, computers should support
>> that. As such designs that make it inconvenient to do so are bad ones.
>
> ????? Human useage is often highly ambiguous, which is why understanding
> natural language is so hard for computers.
> So if they want to put carriage returns into their filename this would
> be OK with you? And is
> apple pear cinammon
> one name or three?  How is the computer to know which it is?
>
>
Very easily. It depends where the delimeters are.

if you try rm apple pear cinnamon and it removes three files, and you 
really only wanted one, try rm apple\ pear\ cinammon

All this gets irrelevant in a GUI where you can type half of a 
shakespeare sonnet into the filename box...
>
>>

On 2016-12-19 10:20, Richard Kettlewell wrote:
> floyd@apaflo.com (Floyd L. Davidson) writes:
>> Chick Tower <c.tower@deadspam.com> wrote:
>>> Too bad there's not a general preference for naming files without
>>> using spaces.
>>
>> But there is exactly that!  Or... amoungt programmers
>> who program for programmers there is that perference.
>> Then along came programmers programming for
>> non-programmers who would not know the difference or
>> difficulties, and would therefore see the use of
>> underscores in place of spaces as an indication of
>> insanity...
>>
>> So we have those who read source code and think spaces
>> in file names is insanity.  And we have those who read
>> onlhy English and think that a lack of spaces in file
>> names is insanity.
> 
> I have been reading and writing computer programs both for a living and
> as a hobby for decades now, and my view is that when humans want to use
> spaces (or anything else) in filenames, computers should support
> that. As such designs that make it inconvenient to do so are bad ones.

My thought exactly.

-- 
Cheers,
       Carlos E.R.

On 2016-12-19 18:24, William Unruh wrote:
> On 2016-12-19, Richard Kettlewell <> wrote:


>> I have been reading and writing computer programs both for a living and
>> as a hobby for decades now, and my view is that when humans want to use
>> spaces (or anything else) in filenames, computers should support
>> that. As such designs that make it inconvenient to do so are bad ones.
> 
> ????? Human useage is often highly ambiguous, which is why understanding
> natural language is so hard for computers. 
> So if they want to put carriage returns into their filename this would
> be OK with you? And is
> apple pear cinammon 
> one name or three?  How is the computer to know which it is?

The computer has no problem at all, the name is stored in a variable of
either known length or null terminated. It is humans who have problems
entering or reading such strings without doubts.

-- 
Cheers,
       Carlos E.R.

On 2016-12-19, William Unruh <unruh@invalid.ca> wrote:

> ????? Human useage is often highly ambiguous, which is why understanding
> natural language is so hard for computers. 
> So if they want to put carriage returns into their filename this would
> be OK with you? And is
> apple pear cinammon 
> one name or three?  How is the computer to know which it is?

cjg@cjglap2:~$ mkdir foo
cjg@cjglap2:~$ cd foo
cjg@cjglap2:~/foo$ touch apple pear cinnamon "apple pear cinnamon"
cjg@cjglap2:~/foo$ ls
apple  apple pear cinnamon  cinnamon  pear
cjg@cjglap2:~/foo$ ls -l
total 0
-rw-r--r-- 1 cjg cjg 0 Dec 19 10:37 apple
-rw-r--r-- 1 cjg cjg 0 Dec 19 10:37 apple pear cinnamon
-rw-r--r-- 1 cjg cjg 0 Dec 19 10:37 cinnamon
-rw-r--r-- 1 cjg cjg 0 Dec 19 10:37 pear
cjg@cjglap2:~/foo$ ls -l "apple pear cinnamon"
-rw-r--r-- 1 cjg cjg 0 Dec 19 10:37 apple pear cinnamon
cjg@cjglap2:~/foo$ ls -l apple pear cinnamon
-rw-r--r-- 1 cjg cjg 0 Dec 19 10:37 apple
-rw-r--r-- 1 cjg cjg 0 Dec 19 10:37 cinnamon
-rw-r--r-- 1 cjg cjg 0 Dec 19 10:37 pear
cjg@cjglap2:~/foo$ ls apple pear cinnamon
apple  cinnamon  pear

Still, I agree that spaces in file names can be a pain.
But users seem to like them, so I've learned to suck it up.
If a user gets sloppy and types two consecutive spaces, or
puts a space at the beginning or the end of a file name,
he gets what he deserves.  And not only do I draw the line
at unprintable characters, I also tell users that they really
shouldn't be using too much punctuation (e.g. colons).

I once read a description of the early Macintosh where it was
said that "you could write a letter to Grandma in the file name."

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

On 2016-12-19, Rich <rich@example.invalid> wrote:

> Any other character _may_ appear in a Linux filename.  Even
> non-printing characters.  

I have an interesting bit of anecdotal evidence for this.
While working with a sort utility on an SVR4 system I discovered
that it defaulted to creating many very small work files.  Since
we were sorting large amounts of data, we wound up with about
12,000 work files.  The numbering scheme for the work file names
was such that one of the digits went past 9 and worked its way
through the ASCII code chart, eventually wrapping around to '\0',
which caused all sorts of problems.  It was fun figuring out how
to delete all those files without hurting anything else.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

At Tue, 20 Dec 2016 03:18:03 +1100 (GMT+11:00) dlbendigo  <laidlaws@hotkey.net.au> wrote:

> 
> William Unruh <unruh@invalid.ca> Wrote in message:
> > On 2016-12-17, gargoyle60 <gargoyle60@example.invalid> wrote:
> >> This will probably explode into a heated debate, but...
> >>
> >> For non-scripting purposes, is there any general rule/preference for quoting filenames with spaces,
> >> i.e. using double-quotes (") or single quotes (')?
> >>
> >> Or is this a matter of personal choice.
> > 
> > Double quotes will allow globs in the filename, single quotes will
> > transmit the globs verbatim
> > 
> > ls "This is*"
> > will list  
> > This is a big file
> > while 
> > ls 'This is*' will list the file with the literal name 
> > This is*
> > So, not preferences but different uses.
> > 
> > 
> 
> If the OP means a file with a filename that includes spaces, not a
>  glob,
> I believe that in Bash, either type of quote will work.
> The Linux Cookbook says that when quoting an expression with an 
> apostrophe, use double quotes.  When quoting an expression that
> already contains double quotes, use single quotes.  It is my 
> understanding that neither of those can be a valid filename.

Anything can be a valid filename character, except possibly newline.

> 
> Doug.

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                                                    

Robert Heller <heller@deepsoft.com> wrote:
> At Tue, 20 Dec 2016 03:18:03 +1100 (GMT+11:00) dlbendigo  <laidlaws@hotkey.net.au> wrote:
> 
>> 
>> William Unruh <unruh@invalid.ca> Wrote in message:
>> > On 2016-12-17, gargoyle60 <gargoyle60@example.invalid> wrote:
>> >> This will probably explode into a heated debate, but...
>> >>
>> >> For non-scripting purposes, is there any general rule/preference for quoting filenames with spaces,
>> >> i.e. using double-quotes (") or single quotes (')?
>> >>
>> >> Or is this a matter of personal choice.
>> > 
>> > Double quotes will allow globs in the filename, single quotes will
>> > transmit the globs verbatim
>> > 
>> > ls "This is*"
>> > will list  
>> > This is a big file
>> > while 
>> > ls 'This is*' will list the file with the literal name 
>> > This is*
>> > So, not preferences but different uses.
>> > 
>> > 
>> 
>> If the OP means a file with a filename that includes spaces, not a
>>  glob,
>> I believe that in Bash, either type of quote will work.
>> The Linux Cookbook says that when quoting an expression with an 
>> apostrophe, use double quotes.  When quoting an expression that
>> already contains double quotes, use single quotes.  It is my 
>> understanding that neither of those can be a valid filename.
> 
> Anything can be a valid filename character, except possibly newline.

Nope.  For Linux only null and / are excluded (now, ls does have to be
"encouraged" to actually print them to a terminal):

  $ touch new$'\n'line
  $ ls --literal --show-control-chars
  new
  line
  $ ls
  new\nline

Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2016-12-19, William Unruh <unruh@invalid.ca> wrote:
> 
>> ????? Human useage is often highly ambiguous, which is why understanding
>> natural language is so hard for computers. 
>> So if they want to put carriage returns into their filename this would
>> be OK with you? And is
>> apple pear cinammon 
>> one name or three?  How is the computer to know which it is?
> 
> ...
> 
> Still, I agree that spaces in file names can be a pain.  But users
> seem to like them, so I've learned to suck it up.

The users who use (and like) them tend to all be GUI users who only
*ever* interact with the filesystem through a file-select dialog of
some form or another.  And in that viewpoint, having spaces in the
filename does not seem like much of a big deal.  They point, they
click, things happen by magic.

It is only the CLI using folks where having spaces (or other
meta-characters) in filenames is a cause of great consternation.

William Unruh <unruh@invalid.ca> writes:
> On 2016-12-19, Richard Kettlewell <invalid@invalid.invalid> wrote:
>> I have been reading and writing computer programs both for a living
>> and as a hobby for decades now, and my view is that when humans want
>> to use spaces (or anything else) in filenames, computers should
>> support that. As such designs that make it inconvenient to do so are
>> bad ones.
>
> ????? Human useage is often highly ambiguous, which is why understanding
> natural language is so hard for computers.

This doesn’t seem to be relevant.

> So if they want to put carriage returns into their filename this would
> be OK with you?

Why should I care?

> And is
> apple pear cinammon 
> one name or three?  How is the computer to know which it is?

By following the rules defining the language or API used to present the
filename, obviously.

-- 
http://www.greenend.org.uk/rjk/

At Mon, 19 Dec 2016 20:19:19 -0000 (UTC) Rich <rich@example.invalid> wrote:

> 
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> > On 2016-12-19, William Unruh <unruh@invalid.ca> wrote:
> > 
> >> ????? Human useage is often highly ambiguous, which is why understanding
> >> natural language is so hard for computers. 
> >> So if they want to put carriage returns into their filename this would
> >> be OK with you? And is
> >> apple pear cinammon 
> >> one name or three?  How is the computer to know which it is?
> > 
> > ...
> > 
> > Still, I agree that spaces in file names can be a pain.  But users
> > seem to like them, so I've learned to suck it up.
> 
> The users who use (and like) them tend to all be GUI users who only
> *ever* interact with the filesystem through a file-select dialog of
> some form or another.  And in that viewpoint, having spaces in the
> filename does not seem like much of a big deal.  They point, they
> click, things happen by magic.
> 
> It is only the CLI using folks where having spaces (or other
> meta-characters) in filenames is a cause of great consternation.

+1

Because I am on dialup, I use a server-side filter (via Procmail with help 
from metamail) to strip off attachments, which I download later via scp. Lots 
and lots of fun from the command line, since it is necessary to quote all of 
the special characters *twice*: once from the local shell and again for the 
remote shell:

scp mail.deepsoft.com:'Mail/Attachments/Stupid\ Ass\ Filename.pdf' ./ProperFilename.pdf

> 
>                                                                                                   

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                                                                                       

On 2016-12-19, Richard Kettlewell <invalid@invalid.invalid> wrote:
> William Unruh <unruh@invalid.ca> writes:
>> On 2016-12-19, Richard Kettlewell <invalid@invalid.invalid> wrote:
>>> I have been reading and writing computer programs both for a living
>>> and as a hobby for decades now, and my view is that when humans want
>>> to use spaces (or anything else) in filenames, computers should
>>> support that. As such designs that make it inconvenient to do so are
>>> bad ones.
>>
>> ????? Human useage is often highly ambiguous, which is why understanding
>> natural language is so hard for computers.
>
> This doesn???t seem to be relevant.
>
>> So if they want to put carriage returns into their filename this would
>> be OK with you?
>
> Why should I care?
>
>> And is
>> apple pear cinammon 
>> one name or three?  How is the computer to know which it is?
>
> By following the rules defining the language or API used to present the
> filename, obviously.
>
You said in your oritinal "such designs that make it inconvenient to do
so are bad ones"
Surely having to put quote marks around "apple pear organge" when those
quote marks are not a part of the fileneame is "inconvenient" or bad.
But if the user just writes the file name
apple pear orange
how the hell is the computer to know if one or three is meant, in
contexts in which one or three are equally lebal according to the rules
of the language? Ie, Your characterisation of "bad" is what I am
objecting to.

The syntax of an unambiguous language, which is what is usually wanted
for communicating with a computer, are at odds with how humans use
language. which is often ambiguous using simple rules.

Robert Heller <heller@deepsoft.com> wrote:
> At Mon, 19 Dec 2016 20:19:19 -0000 (UTC) Rich <rich@example.invalid> wrote:
> 
>> 
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>> > On 2016-12-19, William Unruh <unruh@invalid.ca> wrote:
>> > 
>> >> ????? Human useage is often highly ambiguous, which is why
>> >> understanding natural language is so hard for computers.
>> >> So if they want to put carriage returns into their filename this
>> >> would be OK with you?  And is
>> >> apple pear cinammon 
>> >> one name or three?  How is the computer to know which it is?
>> > 
>> > ...
>> > 
>> > Still, I agree that spaces in file names can be a pain.  But users
>> > seem to like them, so I've learned to suck it up.
>> 
>> The users who use (and like) them tend to all be GUI users who only
>> *ever* interact with the filesystem through a file-select dialog of
>> some form or another.  And in that viewpoint, having spaces in the
>> filename does not seem like much of a big deal.  They point, they
>> click, things happen by magic.
>> 
>> It is only the CLI using folks where having spaces (or other
>> meta-characters) in filenames is a cause of great consternation.
> 
> +1
> 
> Because I am on dialup, I use a server-side filter (via Procmail with
> help from metamail) to strip off attachments, which I download later
> via scp.  Lots and lots of fun from the command line, since it is
> necessary to quote all of the special characters *twice*: once from
> the local shell and again for the remote shell:
> 
> scp mail.deepsoft.com:'Mail/Attachments/Stupid\ Ass\ Filename.pdf' ./ProperFilename.pdf

If you can 'scp', could you not also run a script on the remote end
that would first rename the files before you attempt to download them?

William Unruh <unruh@invalid.ca> writes:
> Richard Kettlewell <invalid@invalid.invalid> wrote:
>> William Unruh <unruh@invalid.ca> writes:
>>> And is
>>> apple pear cinammon 
>>> one name or three?  How is the computer to know which it is?
>>
>> By following the rules defining the language or API used to present the
>> filename, obviously.
>
> You said in your oritinal "such designs that make it inconvenient to do
> so are bad ones"
> Surely having to put quote marks around "apple pear organge" when those
> quote marks are not a part of the fileneame is "inconvenient" or bad.

In the context of a human typing, not really, no. Tab completion will
usually automate it anyway.

The serious problem with shell is that it’s unnecessarily difficult (at
various levels, up to and including exploitable vulnerabilities) to
write programs in it that correctly handle strings with spaces (or
certain kinds of punctuation) in.

The obsession with spaces in filenames a bit weird, really - banning
them wouldn’t actually fix the underlying problem, it would just reduce
its scope slightly.

> But if the user just writes the file name
> apple pear orange
> how the hell is the computer to know if one or three is meant, in
> contexts in which one or three are equally lebal according to the rules
> of the language?
> Ie, Your characterisation of "bad" is what I am objecting to.

Repeating the question doesn’t change the answer.  It is also a little
strange to ask how a computer is supposed to solve a problem that has
already been solved.

-- 
http://www.greenend.org.uk/rjk/

On 2016-12-19 22:43, William Unruh wrote:
> On 2016-12-19, Richard Kettlewell <invalid@invalid.invalid> wrote:


> You said in your oritinal "such designs that make it inconvenient to do
> so are bad ones"
> Surely having to put quote marks around "apple pear organge" when those
> quote marks are not a part of the fileneame is "inconvenient" or bad.
> But if the user just writes the file name
> apple pear orange
> how the hell is the computer to know if one or three is meant, in
> contexts in which one or three are equally lebal according to the rules
> of the language? Ie, Your characterisation of "bad" is what I am
> objecting to.

If the user writes to the computer, in the command line,

apple pear orange

he is without doubt specifying three names. Simply because the rules of
the language say so... The computer has no doubts.

If you tell to the user: "give me a file name and press enter" then,
obviously, everything till line end is a single name. It is up to you,
the programmer, to make sure that it works.

You can also tell the user what chars are invalid, and check for them.

The computer never has doubts.

Whether the computer thinks the same as you, now, that's different. And
they pay you to know :-P


Yes, spaces can be a pain. I use spaces in file names, they give clarity
in long names. Yes, I hate myself when I write scripts. So?

:-)

-- 
Cheers,
       Carlos E.R.

On 2016-12-19, Carlos E. R. <robin_listas@invalid.es> wrote:
> On 2016-12-19 22:43, William Unruh wrote:
>> On 2016-12-19, Richard Kettlewell <invalid@invalid.invalid> wrote:
>
>
>> You said in your oritinal "such designs that make it inconvenient to do
>> so are bad ones"
>> Surely having to put quote marks around "apple pear organge" when those
>> quote marks are not a part of the fileneame is "inconvenient" or bad.
>> But if the user just writes the file name
>> apple pear orange
>> how the hell is the computer to know if one or three is meant, in
>> contexts in which one or three are equally lebal according to the rules
>> of the language? Ie, Your characterisation of "bad" is what I am
>> objecting to.
>
> If the user writes to the computer, in the command line,
>
> apple pear orange

But if the human wanted that to refer to one file with a name with
spaces, the computer is definite and wrong. 

>
> he is without doubt specifying three names. Simply because the rules of
> the language say so... The computer has no doubts.

I agree that the computer has no doubt. It is certain, and wrong. 

>
> If you tell to the user: "give me a file name and press enter" then,
> obviously, everything till line end is a single name. It is up to you,
> the programmer, to make sure that it works.

the command "rm" says, give me a list of file names and press enter. Now
the white space causes it to give the worng answer. 


>
> You can also tell the user what chars are invalid, and check for them.
>
> The computer never has doubts.
>
> Whether the computer thinks the same as you, now, that's different. And
> they pay you to know :-P
>
>
> Yes, spaces can be a pain. I use spaces in file names, they give clarity
> in long names. Yes, I hate myself when I write scripts. So?

It was the claim that anytime when the computer is confused by things
humans do is bad that I was objecting to. 


>
>:-)
>

At Mon, 19 Dec 2016 22:26:58 -0000 (UTC) Rich <rich@example.invalid> wrote:

> 
> Robert Heller <heller@deepsoft.com> wrote:
> > At Mon, 19 Dec 2016 20:19:19 -0000 (UTC) Rich <rich@example.invalid> wrote:
> > 
> >> 
> >> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> >> > On 2016-12-19, William Unruh <unruh@invalid.ca> wrote:
> >> > 
> >> >> ????? Human useage is often highly ambiguous, which is why
> >> >> understanding natural language is so hard for computers.
> >> >> So if they want to put carriage returns into their filename this
> >> >> would be OK with you?  And is
> >> >> apple pear cinammon 
> >> >> one name or three?  How is the computer to know which it is?
> >> > 
> >> > ...
> >> > 
> >> > Still, I agree that spaces in file names can be a pain.  But users
> >> > seem to like them, so I've learned to suck it up.
> >> 
> >> The users who use (and like) them tend to all be GUI users who only
> >> *ever* interact with the filesystem through a file-select dialog of
> >> some form or another.  And in that viewpoint, having spaces in the
> >> filename does not seem like much of a big deal.  They point, they
> >> click, things happen by magic.
> >> 
> >> It is only the CLI using folks where having spaces (or other
> >> meta-characters) in filenames is a cause of great consternation.
> > 
> > +1
> > 
> > Because I am on dialup, I use a server-side filter (via Procmail with
> > help from metamail) to strip off attachments, which I download later
> > via scp.  Lots and lots of fun from the command line, since it is
> > necessary to quote all of the special characters *twice*: once from
> > the local shell and again for the remote shell:
> > 
> > scp mail.deepsoft.com:'Mail/Attachments/Stupid\ Ass\ Filename.pdf' ./ProperFilename.pdf
> 
> If you can 'scp', could you not also run a script on the remote end
> that would first rename the files before you attempt to download them?

There isn't any sort of *consistent* naming (silly stupid mess-windows &
MacOSX point-and-click idiots that randomly name files in random ways). I
would have to write a one-of script for each instance. And sometimes I need to
preserve the name for various strange reasons. And sometimes the original name
is really bogus (like an extra space before the final dot). Or leading spaces
or other strange and wonderful meta characters tossed in randomly (like & and
$). Whether I double escape the scp call or double the escaping the 'ssh
mail.deepsoft.com mv ...', it is equally awkward. Also I get all sort of
*junk* attachments that I will never download -- I don't want to waste the
effort to rename them. Oh and just to make things strange, because *I* refuse
to deal with mess-word files (.doc or .docx), people will export them to PDF
(which really should have done in the first place) and then name the file
something stupid like "Stupid Ass Filename PDF.pdf" (where the original was
"Stupid Ass Filename.doc").  Both mess-windows and MacOSX "hide" the 
extensions so people don't realise that they can really have both "Stupid Ass 
Filename.doc" and "Stupid Ass Filename.pdf" on their desktop *at the same 
time* and the two files will actually get different icons, so there isn't any 
need to give them different names.

> 
>              

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                                   

On 2016-12-20 00:21, William Unruh wrote:
> On 2016-12-19, Carlos E. R. <robin_listas@invalid.es> wrote:
>> On 2016-12-19 22:43, William Unruh wrote:
>>> On 2016-12-19, Richard Kettlewell <invalid@invalid.invalid> wrote:
>>
>>
>>> You said in your oritinal "such designs that make it inconvenient to do
>>> so are bad ones"
>>> Surely having to put quote marks around "apple pear organge" when those
>>> quote marks are not a part of the fileneame is "inconvenient" or bad.
>>> But if the user just writes the file name
>>> apple pear orange
>>> how the hell is the computer to know if one or three is meant, in
>>> contexts in which one or three are equally lebal according to the rules
>>> of the language? Ie, Your characterisation of "bad" is what I am
>>> objecting to.
>>
>> If the user writes to the computer, in the command line,
>>
>> apple pear orange
> 
> But if the human wanted that to refer to one file with a name with
> spaces, the computer is definite and wrong. 

No, the user wrote it wrong :-)


>>
>> he is without doubt specifying three names. Simply because the rules of
>> the language say so... The computer has no doubts.
> 
> I agree that the computer has no doubt. It is certain, and wrong. 

The user did not use the right syntax. The computer did what it was told
to do, exactly.


>> If you tell to the user: "give me a file name and press enter" then,
>> obviously, everything till line end is a single name. It is up to you,
>> the programmer, to make sure that it works.
> 
> the command "rm" says, give me a list of file names and press enter. Now
> the white space causes it to give the worng answer. 

No, because "rm" is expecting certain syntax that the user did not use
correctly.



>> You can also tell the user what chars are invalid, and check for them.
>>
>> The computer never has doubts.
>>
>> Whether the computer thinks the same as you, now, that's different. And
>> they pay you to know :-P
>>
>>
>> Yes, spaces can be a pain. I use spaces in file names, they give clarity
>> in long names. Yes, I hate myself when I write scripts. So?
> 
> It was the claim that anytime when the computer is confused by things
> humans do is bad that I was objecting to. 

The computer is not confused, it is doing exactly what it is told, by
the programmer and by the user. It is the programmer fault for not
taking everything into account, or the user for not following the manual
strictly. Which is difficult, he is not a programmer.


-- 
Cheers,
       Carlos E.R.

On 2016-12-19, Robert Heller <heller@deepsoft.com> wrote:

> There isn't any sort of *consistent* naming (silly stupid mess-windows &
> MacOSX point-and-click idiots that randomly name files in random ways).

I feel your pain.

> I would have to write a one-of script for each instance. And sometimes I need
> to preserve the name for various strange reasons. And sometimes the original
> name is really bogus (like an extra space before the final dot). Or leading
> spaces or other strange and wonderful meta characters tossed in randomly (like
> & and $). Whether I double escape the scp call or double the escaping the 'ssh
> mail.deepsoft.com mv ...', it is equally awkward. Also I get all sort of
> *junk* attachments that I will never download -- I don't want to waste the
> effort to rename them.

One thing you could do - if you're trying to get every file in a given
directory - is have your script zip everything (e.g. zip ~/stuff.zip *)
and send one file that could well be considerably smaller.  If you need
to pick and choose the files... well, as Roseann Roseannadanna used to
say, "Never mind."

> Oh and just to make things strange, because *I* refuse to deal with
> mess-word files (.doc or .docx), people will export them to PDF (which
> really should have done in the first place) and then name the file
> something stupid like "Stupid Ass Filename PDF.pdf" (where the original
> was "Stupid Ass Filename.doc").

Unless they get really clever and export "Stupid Ass Filename.doc" to
"zzzzzzzz.pdf".  Perhaps they'll call the next file "zzzzzzzzz.pdf", etc.

> Both mess-windows and MacOSX "hide" the extensions so people don't realise
> that they can really have both "Stupid Ass Filename.doc" and "Stupid Ass
> Filename.pdf" on their desktop *at the same time* and the two files will
> actually get different icons, so there isn't any need to give them different
> names.

Of course, this opens the door to some nasty person sending them a file
called "Stupid Ass Filename.doc.exe".  On the other hand, this might keep
them out of your hair for the time it takes them to rebuild everything that's
lost on their now-malware-infested machine - unless it is your responsibility
(whether real or imagined on their part) to clean up the mess.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

On 2016-12-19, William Unruh <unruh@invalid.ca> wrote:

> On 2016-12-19, Carlos E. R. <robin_listas@invalid.es> wrote:
>
>> If the user writes to the computer, in the command line,
>>
>> apple pear orange
>
> But if the human wanted that to refer to one file with a name with
> spaces, the computer is definite and wrong. 

FSVO "wrong".  Your definition of "wrong" is "doesn't read the user's
mind."  That's the problem with these pesky machines - they insist on
doing what you tell them to do, not what you want them to do.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

Robert Heller <heller@deepsoft.com> wrote:
> At Mon, 19 Dec 2016 22:26:58 -0000 (UTC) Rich <rich@example.invalid> wrote:
> 
>> 
>> Robert Heller <heller@deepsoft.com> wrote:
>> > At Mon, 19 Dec 2016 20:19:19 -0000 (UTC) Rich <rich@example.invalid> wrote:
>> > 
>> >> 
>> >> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>> >> > On 2016-12-19, William Unruh <unruh@invalid.ca> wrote:
>> >> >> ????? Human useage is often highly ambiguous, which is why
>> >> >> understanding natural language is so hard for computers.
>> >> >> So if they want to put carriage returns into their filename this
>> >> >> would be OK with you?  And is
>> >> >> apple pear cinammon 
>> >> >> one name or three?  How is the computer to know which it is?
>> >> > 
>> >> > Still, I agree that spaces in file names can be a pain.  But users
>> >> > seem to like them, so I've learned to suck it up.
>> >> 
>> >> The users who use (and like) them tend to all be GUI users who only
>> >> *ever* interact with the filesystem through a file-select dialog of
>> >> some form or another.  And in that viewpoint, having spaces in the
>> >> filename does not seem like much of a big deal.  They point, they
>> >> click, things happen by magic.
>> >> 
>> >> It is only the CLI using folks where having spaces (or other
>> >> meta-characters) in filenames is a cause of great consternation.
>> > 
>> > +1
>> > 
>> > Because I am on dialup, I use a server-side filter (via Procmail with
>> > help from metamail) to strip off attachments, which I download later
>> > via scp.  Lots and lots of fun from the command line, since it is
>> > necessary to quote all of the special characters *twice*: once from
>> > the local shell and again for the remote shell:
>> > 
>> > scp mail.deepsoft.com:'Mail/Attachments/Stupid\ Ass\ Filename.pdf' ./ProperFilename.pdf
>> 
>> If you can 'scp', could you not also run a script on the remote end
>> that would first rename the files before you attempt to download them?
> 
> There isn't any sort of *consistent* naming (silly stupid mess-windows &
> MacOSX point-and-click idiots that randomly name files in random ways). I
> would have to write a one-of script for each instance. And sometimes I need to
> preserve the name for various strange reasons.

Or, you could do something like encode any character that is not
[-a-zA-Z0-9.] into something like URL encoding (%XX where XX is the hex
value of the original byte).  It would make things look ugly, but would
preserve the original names, contain no spaces, would not need to be a
one-off for each case, and save you from having to work out just the
right number of leaning toothpicks to get the weird character past two
shells.

> Oh and just to make things strange, because *I* refuse to deal with
> mess-word files (.doc or .docx), people will export them to PDF
> (which really should have done in the first place) and then name the
> file something stupid like "Stupid Ass Filename PDF.pdf" (where the
> original was "Stupid Ass Filename.doc").  Both mess-windows and
> MacOSX "hide" the extensions so people don't realise that they can
> really have both "Stupid Ass Filename.doc" and "Stupid Ass
> Filename.pdf" on their desktop *at the same time* and the two files
> will actually get different icons, so there isn't any need to give
> them different names.

Yeah, the blame for that one lies squarely with microsoft.  That has
also been a huge source of security issues for them (xyz.pdf.exe to
name a few).

Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> Unless they get really clever and export "Stupid Ass Filename.doc" to
> "zzzzzzzz.pdf".  Perhaps they'll call the next file "zzzzzzzzz.pdf", etc.

I've seen the occasional instance where they perform this command, only
from windows explorer, answering "yes" to the are you sure prompt, and
think they've 'fixed' things:

  mv "Stupid Ass Filename.doc" "Stupid Ass Filename.pdf".

Yep, they actually think that by simply changing the name, that what
was a doc before is now, by magic, a pdf.

On 2016-12-20, Carlos E. R. <robin_listas@invalid.es> wrote:
> On 2016-12-20 00:21, William Unruh wrote:
>> On 2016-12-19, Carlos E. R. <robin_listas@invalid.es> wrote:
>>> On 2016-12-19 22:43, William Unruh wrote:
>>>> On 2016-12-19, Richard Kettlewell <invalid@invalid.invalid> wrote:
>>>
>>>
>>>> You said in your oritinal "such designs that make it inconvenient to do
>>>> so are bad ones"
>>>> Surely having to put quote marks around "apple pear organge" when those
>>>> quote marks are not a part of the fileneame is "inconvenient" or bad.
>>>> But if the user just writes the file name
>>>> apple pear orange
>>>> how the hell is the computer to know if one or three is meant, in
>>>> contexts in which one or three are equally lebal according to the rules
>>>> of the language? Ie, Your characterisation of "bad" is what I am
>>>> objecting to.
>>>
>>> If the user writes to the computer, in the command line,
>>>
>>> apple pear orange
>> 
>> But if the human wanted that to refer to one file with a name with
>> spaces, the computer is definite and wrong. 
>
> No, the user wrote it wrong :-)

Again, you did not read or remember the sentence I was objecting to. I
will not quote it again.

>
>
>>>
>>> he is without doubt specifying three names. Simply because the rules of
>>> the language say so... The computer has no doubts.
>> 
>> I agree that the computer has no doubt. It is certain, and wrong. 
>
> The user did not use the right syntax. The computer did what it was told
> to do, exactly.
>
>
>>> If you tell to the user: "give me a file name and press enter" then,
>>> obviously, everything till line end is a single name. It is up to you,
>>> the programmer, to make sure that it works.
>> 
>> the command "rm" says, give me a list of file names and press enter. Now
>> the white space causes it to give the worng answer. 
>
> No, because "rm" is expecting certain syntax that the user did not use
> correctly.
>
>
>
>>> You can also tell the user what chars are invalid, and check for them.
>>>
>>> The computer never has doubts.
>>>
>>> Whether the computer thinks the same as you, now, that's different. And
>>> they pay you to know :-P
>>>
>>>
>>> Yes, spaces can be a pain. I use spaces in file names, they give clarity
>>> in long names. Yes, I hate myself when I write scripts. So?
>> 
>> It was the claim that anytime when the computer is confused by things
>> humans do is bad that I was objecting to. 
>
> The computer is not confused, it is doing exactly what it is told, by
> the programmer and by the user. It is the programmer fault for not
> taking everything into account, or the user for not following the manual
> strictly. Which is difficult, he is not a programmer.

>
>

On 2016-12-20, Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

> One thing you could do - if you're trying to get every file in a given
> directory - is have your script zip everything (e.g. zip ~/stuff.zip *)
> and send one file that could well be considerably smaller.  If you need
> to pick and choose the files... well, as Roseann Roseannadanna used to
> say, "Never mind."

s/Roseann Roseannadanna/Emily Litella/

"Don't you hate it when that happens?"  -- Beetlejuice

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

On Mon, 19 Dec 2016 09:23:01 +0000, gargoyle60 <gargoyle60@example.invalid> wrote:

>Thanks for all the answers

I should have added...
Although currently working within Windows XP to perform the copying of files to a spare Windows
partition, I wanted my batch script to be compatible with Linux CLI and shell, eventually to be used
via a shell script finally to copy the files to a Linux partition.

At 20 Dec 2016 01:43:50 GMT Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

> 
> On 2016-12-19, Robert Heller <heller@deepsoft.com> wrote:
> 
> > There isn't any sort of *consistent* naming (silly stupid mess-windows &
> > MacOSX point-and-click idiots that randomly name files in random ways).
> 
> I feel your pain.
> 
> > I would have to write a one-of script for each instance. And sometimes I need
> > to preserve the name for various strange reasons. And sometimes the original
> > name is really bogus (like an extra space before the final dot). Or leading
> > spaces or other strange and wonderful meta characters tossed in randomly (like
> > & and $). Whether I double escape the scp call or double the escaping the 'ssh
> > mail.deepsoft.com mv ...', it is equally awkward. Also I get all sort of
> > *junk* attachments that I will never download -- I don't want to waste the
> > effort to rename them.
> 
> One thing you could do - if you're trying to get every file in a given
> directory - is have your script zip everything (e.g. zip ~/stuff.zip *)
> and send one file that could well be considerably smaller.  If you need
> to pick and choose the files... well, as Roseann Roseannadanna used to
> say, "Never mind."

99% of the "junk" that metamail extracts gets tossed.

> 
> > Oh and just to make things strange, because *I* refuse to deal with
> > mess-word files (.doc or .docx), people will export them to PDF (which
> > really should have done in the first place) and then name the file
> > something stupid like "Stupid Ass Filename PDF.pdf" (where the original
> > was "Stupid Ass Filename.doc").
> 
> Unless they get really clever and export "Stupid Ass Filename.doc" to
> "zzzzzzzz.pdf".  Perhaps they'll call the next file "zzzzzzzzz.pdf", etc.
> 
> > Both mess-windows and MacOSX "hide" the extensions so people don't realise
> > that they can really have both "Stupid Ass Filename.doc" and "Stupid Ass
> > Filename.pdf" on their desktop *at the same time* and the two files will
> > actually get different icons, so there isn't any need to give them different
> > names.
> 
> Of course, this opens the door to some nasty person sending them a file
> called "Stupid Ass Filename.doc.exe".  On the other hand, this might keep
> them out of your hair for the time it takes them to rebuild everything that's
> lost on their now-malware-infested machine - unless it is your responsibility
> (whether real or imagined on their part) to clean up the mess.
> 

Not my problem. I have no reason to ever download a .exe file, so they all get 
filed in the circular file -- eg get fatally attached by the RMStar.  


-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                                                      

At Tue, 20 Dec 2016 01:56:49 -0000 (UTC) Rich <rich@example.invalid> wrote:

> 
> Robert Heller <heller@deepsoft.com> wrote:
> > At Mon, 19 Dec 2016 22:26:58 -0000 (UTC) Rich <rich@example.invalid> wrote:
> > 
> >> 
> >> Robert Heller <heller@deepsoft.com> wrote:
> >> > At Mon, 19 Dec 2016 20:19:19 -0000 (UTC) Rich <rich@example.invalid> wrote:
> >> > 
> >> >> 
> >> >> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> >> >> > On 2016-12-19, William Unruh <unruh@invalid.ca> wrote:
> >> >> >> ????? Human useage is often highly ambiguous, which is why
> >> >> >> understanding natural language is so hard for computers.
> >> >> >> So if they want to put carriage returns into their filename this
> >> >> >> would be OK with you?  And is
> >> >> >> apple pear cinammon 
> >> >> >> one name or three?  How is the computer to know which it is?
> >> >> > 
> >> >> > Still, I agree that spaces in file names can be a pain.  But users
> >> >> > seem to like them, so I've learned to suck it up.
> >> >> 
> >> >> The users who use (and like) them tend to all be GUI users who only
> >> >> *ever* interact with the filesystem through a file-select dialog of
> >> >> some form or another.  And in that viewpoint, having spaces in the
> >> >> filename does not seem like much of a big deal.  They point, they
> >> >> click, things happen by magic.
> >> >> 
> >> >> It is only the CLI using folks where having spaces (or other
> >> >> meta-characters) in filenames is a cause of great consternation.
> >> > 
> >> > +1
> >> > 
> >> > Because I am on dialup, I use a server-side filter (via Procmail with
> >> > help from metamail) to strip off attachments, which I download later
> >> > via scp.  Lots and lots of fun from the command line, since it is
> >> > necessary to quote all of the special characters *twice*: once from
> >> > the local shell and again for the remote shell:
> >> > 
> >> > scp mail.deepsoft.com:'Mail/Attachments/Stupid\ Ass\ Filename.pdf' ./ProperFilename.pdf
> >> 
> >> If you can 'scp', could you not also run a script on the remote end
> >> that would first rename the files before you attempt to download them?
> > 
> > There isn't any sort of *consistent* naming (silly stupid mess-windows &
> > MacOSX point-and-click idiots that randomly name files in random ways). I
> > would have to write a one-of script for each instance. And sometimes I need to
> > preserve the name for various strange reasons.
> 
> Or, you could do something like encode any character that is not
> [-a-zA-Z0-9.] into something like URL encoding (%XX where XX is the hex
> value of the original byte).  It would make things look ugly, but would
> preserve the original names, contain no spaces, would not need to be a
> one-off for each case, and save you from having to work out just the
> right number of leaning toothpicks to get the weird character past two
> shells.
> 
> > Oh and just to make things strange, because *I* refuse to deal with
> > mess-word files (.doc or .docx), people will export them to PDF
> > (which really should have done in the first place) and then name the
> > file something stupid like "Stupid Ass Filename PDF.pdf" (where the
> > original was "Stupid Ass Filename.doc").  Both mess-windows and
> > MacOSX "hide" the extensions so people don't realise that they can
> > really have both "Stupid Ass Filename.doc" and "Stupid Ass
> > Filename.pdf" on their desktop *at the same time* and the two files
> > will actually get different icons, so there isn't any need to give
> > them different names.
> 
> Yeah, the blame for that one lies squarely with microsoft.  That has
> also been a huge source of security issues for them (xyz.pdf.exe to
> name a few).

Apple shares some of the guilt -- old (Clasic) MacOS never enforced the use of 
extensions at all (oh those "fun" 4-byte Creator codes and Type codes...)

> 
>                                               

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                                                                             

The Natural Philosopher <tnp@invalid.invalid> writes:
> On 18/12/16 21:13, Robert Heller wrote:
>> Blame Apple, who basicly "invented" file names with spaces. (M$ was
>> just copycatting MacOS.)
>
> surely Unix had spaced filenames before either?

It was capable of them since the early days, indeed - but I don’t think
there was much tradition of actually using them.

-- 
http://www.greenend.org.uk/rjk/

On 2016-12-19, The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 19/12/16 19:24, William Unruh wrote:
>> On 2016-12-19, Richard Kettlewell <invalid@invalid.invalid> wrote:
>>> floyd@apaflo.com (Floyd L. Davidson) writes:
>>>> Chick Tower <c.tower@deadspam.com> wrote:
>>>>> Too bad there's not a general preference for naming files without
>>>>> using spaces.
>>>>
>>>> But there is exactly that!  Or... amoungt programmers
>>>> who program for programmers there is that perference.
>>>> Then along came programmers programming for
>>>> non-programmers who would not know the difference or
>>>> difficulties, and would therefore see the use of
>>>> underscores in place of spaces as an indication of
>>>> insanity...
>>>>
>>>> So we have those who read source code and think spaces
>>>> in file names is insanity.  And we have those who read
>>>> onlhy English and think that a lack of spaces in file
>>>> names is insanity.
>>>
>>> I have been reading and writing computer programs both for a living and
>>> as a hobby for decades now, and my view is that when humans want to use
>>> spaces (or anything else) in filenames, computers should support
>>> that. As such designs that make it inconvenient to do so are bad ones.
>>
>> ????? Human useage is often highly ambiguous, which is why understanding
>> natural language is so hard for computers.
>> So if they want to put carriage returns into their filename this would
>> be OK with you? And is
>> apple pear cinammon
>> one name or three?  How is the computer to know which it is?
>>
>>
> Very easily. It depends where the delimeters are.
>
> if you try rm apple pear cinnamon and it removes three files, and you 
> really only wanted one, try rm apple\ pear\ cinammon
>
> All this gets irrelevant in a GUI where you can type half of a 
> shakespeare sonnet into the filename box...

Yes, I know how to do it. That is not the point. for example a file name 

`!~@#$%^&*()-_=+[{]}\|:;"'<,>.?/

can be removed or erased. But it is certainly neither obvious or easy.

'`!~@#$%^&*()-_=+[{]}\|:;"'"'"'<,>.?/'
will do it. But no amount of \ will. Nor will any use of just " or '

>>
>>>
>

On 20/12/16 17:38, Richard Kettlewell wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>> On 18/12/16 21:13, Robert Heller wrote:
>>> Blame Apple, who basicly "invented" file names with spaces. (M$ was
>>> just copycatting MacOS.)
>>
>> surely Unix had spaced filenames before either?
>
> It was capable of them since the early days, indeed - but I don’t think
> there was much tradition of actually using them.
>
Oh, pretty sure we did....as users anyway - the system never did.

On 20/12/16 18:25, William Unruh wrote:
> On 2016-12-19, The Natural Philosopher <tnp@invalid.invalid> wrote:
>> On 19/12/16 19:24, William Unruh wrote:
>>> On 2016-12-19, Richard Kettlewell <invalid@invalid.invalid> wrote:
>>>> floyd@apaflo.com (Floyd L. Davidson) writes:
>>>>> Chick Tower <c.tower@deadspam.com> wrote:
>>>>>> Too bad there's not a general preference for naming files without
>>>>>> using spaces.
>>>>>
>>>>> But there is exactly that!  Or... amoungt programmers
>>>>> who program for programmers there is that perference.
>>>>> Then along came programmers programming for
>>>>> non-programmers who would not know the difference or
>>>>> difficulties, and would therefore see the use of
>>>>> underscores in place of spaces as an indication of
>>>>> insanity...
>>>>>
>>>>> So we have those who read source code and think spaces
>>>>> in file names is insanity.  And we have those who read
>>>>> onlhy English and think that a lack of spaces in file
>>>>> names is insanity.
>>>>
>>>> I have been reading and writing computer programs both for a living and
>>>> as a hobby for decades now, and my view is that when humans want to use
>>>> spaces (or anything else) in filenames, computers should support
>>>> that. As such designs that make it inconvenient to do so are bad ones.
>>>
>>> ????? Human useage is often highly ambiguous, which is why understanding
>>> natural language is so hard for computers.
>>> So if they want to put carriage returns into their filename this would
>>> be OK with you? And is
>>> apple pear cinammon
>>> one name or three?  How is the computer to know which it is?
>>>
>>>
>> Very easily. It depends where the delimeters are.
>>
>> if you try rm apple pear cinnamon and it removes three files, and you
>> really only wanted one, try rm apple\ pear\ cinammon
>>
>> All this gets irrelevant in a GUI where you can type half of a
>> shakespeare sonnet into the filename box...
>
> Yes, I know how to do it. That is not the point. for example a file name
>
> `!~@#$%^&*()-_=+[{]}\|:;"'<,>.?/
>
> can be removed or erased. But it is certainly neither obvious or easy.
>
> '`!~@#$%^&*()-_=+[{]}\|:;"'"'"'<,>.?/'
> will do it. But no amount of \ will. Nor will any use of just " or '

rm *=+*


>>>
>>>>
>>

At Mon, 19 Dec 2016 15:21:37 +0200 The Natural Philosopher <tnp@invalid.invalid> wrote:

> 
> On 19/12/16 11:23, gargoyle60 wrote:
> > On Sat, 17 Dec 2016 11:55:47 +0000, gargoyle60 <gargoyle60@example.invalid> wrote:
> >
> > Thanks for all the answers.
> >
> > [Within Windows] I am copying filenames with spaces from an old Windows partition and converting the
> > spaces to underscores (my own preference from my old UNIX days), but couldn't remember if there was
> > a general preference for using double-quotes or single quotes for the original filenames with
> > spaces.
> > My personal preference is to use single but I thought is worthwhile to get a general consensus, if
> > any.
> >
> > Having said that, I have run into problems with using WZUNZIP.EXE under WinXP with single quotes
> > with some filenames, so for unzipping operation prior to copying I have had to use double quotes as
> > the exception.
> >
> I discovered that my minidlna player couldn't handle multiple periods 
> and OS/X REALlY didn't like colons. I don't suppose windows does either.

MacOSX and MS-Windows use colons for volumes.

> 
> All were happy with spaces. Linux was happy with ANYTHING.

Colons can be an issue if you are also using scp (or rsync):

scp foo:bar otherhost:destdir/

where 'foo:bar' is just a local file name.  Opps...  

> 
>           

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                                                                                           

At Mon, 19 Dec 2016 14:31:06 +0200 The Natural Philosopher <tnp@invalid.invalid> wrote:

> 
> On 18/12/16 21:13, Robert Heller wrote:
> > Blame Apple, who basicly "invented" file names with spaces. (M$ was just
> > copycatting MacOS.)
> 
> surely Unix had spaced filenames before either?

Command line UNIX greatly discuraged filenames with spaces (and other meta
characters), since entering them on the CLI was/is a pain in the ass -- all of
the quoting needed -- it is just easier to type a dash or underscore than a
backslash and a space. Or use the shift key at the beginning of words.

With the advent of point-and-click GUIs, filenames with spaces became 
possible.  For the most part (until really recently), old school UNIX users 
had become used to filenames without spaces and have come up with various 
space alternitives (dashes, underscores, camel case, etc.) and mostly 
continuted to do that, even with GUI interfaces.  Non-UNIX users (MacOS, 
MS-Windows), did not have any CLI history and and are more natrual-language 
oriented and use spaces, etc. with abandon.

> 
>                                             

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                              

On 2016-12-20, The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 20/12/16 18:25, William Unruh wrote:
>> On 2016-12-19, The Natural Philosopher <tnp@invalid.invalid> wrote:
>>> On 19/12/16 19:24, William Unruh wrote:
>>>> On 2016-12-19, Richard Kettlewell <invalid@invalid.invalid> wrote:
>>>>> floyd@apaflo.com (Floyd L. Davidson) writes:
>>>>>> Chick Tower <c.tower@deadspam.com> wrote:
>>>>>>> Too bad there's not a general preference for naming files without
>>>>>>> using spaces.
>>>>>>
>>>>>> But there is exactly that!  Or... amoungt programmers
>>>>>> who program for programmers there is that perference.
>>>>>> Then along came programmers programming for
>>>>>> non-programmers who would not know the difference or
>>>>>> difficulties, and would therefore see the use of
>>>>>> underscores in place of spaces as an indication of
>>>>>> insanity...
>>>>>>
>>>>>> So we have those who read source code and think spaces
>>>>>> in file names is insanity.  And we have those who read
>>>>>> onlhy English and think that a lack of spaces in file
>>>>>> names is insanity.
>>>>>
>>>>> I have been reading and writing computer programs both for a living and
>>>>> as a hobby for decades now, and my view is that when humans want to use
>>>>> spaces (or anything else) in filenames, computers should support
>>>>> that. As such designs that make it inconvenient to do so are bad ones.
>>>>
>>>> ????? Human useage is often highly ambiguous, which is why understanding
>>>> natural language is so hard for computers.
>>>> So if they want to put carriage returns into their filename this would
>>>> be OK with you? And is
>>>> apple pear cinammon
>>>> one name or three?  How is the computer to know which it is?
>>>>
>>>>
>>> Very easily. It depends where the delimeters are.
>>>
>>> if you try rm apple pear cinnamon and it removes three files, and you
>>> really only wanted one, try rm apple\ pear\ cinammon
>>>
>>> All this gets irrelevant in a GUI where you can type half of a
>>> shakespeare sonnet into the filename box...
>>
>> Yes, I know how to do it. That is not the point. for example a file name
>>
>> `!~@#$%^&*()-_=+[{]}\|:;"'<,>.?/
>>
>> can be removed or erased. But it is certainly neither obvious or easy.
>>
>> '`!~@#$%^&*()-_=+[{]}\|:;"'"'"'<,>.?/'
>> will do it. But no amount of \ will. Nor will any use of just " or '
>
> rm *=+*

But that will also erase all of those hundreds of other files with
almost the same name which also have =+ in them! :-)
And it would also not work if there were a tab or space as well in the
filename.

Ie, while it is certainly possible to accomplish stuff with weird
filenames, it is not straightforward and takes extra effort. Note that I
gave a way to accompish what was needed. But it took thought and work,
and a very careful reading of bash manual (eg that ' is never escaped
inside single quotes even with a \ in front of it.)


>
>
>>>>
>>>>>
>>>
>

Robert Heller <heller@deepsoft.com> wrote:
> And sometimes the original name is really bogus (like an extra space
> before the final dot).

At times I have engaged in precisely that bogosity, when requested to use
filenames with spaces in them, because to my eyes "." binds more tightly
than " " (just as "*" binds more tightly than "+" in "1+2*3"), and I parse
"My First Word Document.doc" as having ".doc" as a modifier of "Document"
rather than of "My First Word Document".  (Also partly done to tease those
who wanted the spaces in the first place.)

Consequently I have a directory in my work account that ls shows as:

   JWW Travel Expense 2004-08 .xls
   JWW Travel Expense 2006-10 .xls
   JWW Travel Expense 2007-02 .xls
   :
   :

Use of Excel was not my choice, of course.

-- 
John Wingate                        Mathematics is the art which teaches
johnww@tds.net                      one how not to make calculations.
                                                         --Oscar Chisini

Robert Heller <heller@deepsoft.com> writes:
> With the advent of point-and-click GUIs, filenames with spaces became 
> possible.  For the most part (until really recently), old school UNIX users 
> had become used to filenames without spaces and have come up with various 
> space alternitives (dashes, underscores, camel case, etc.) and mostly 
> continuted to do that, even with GUI interfaces.  Non-UNIX users (MacOS, 
> MS-Windows), did not have any CLI history and and are more natrual-language 
> oriented and use spaces, etc. with abandon.

The early Windows users were basically all MSDOS users.  I don’t think
the cultural-historical argument works for them.

-- 
http://www.greenend.org.uk/rjk/

Robert Heller <hel...@deepsoft.com> [RH]:
RH> Colons can be an issue if you are also using scp (or rsync):
RH>
RH> scp foo:bar otherhost:destdir/
RH>
RH> where 'foo:bar' is just a local file name.  Opps...

Add 'tar' and 'cpio' to the list of commands that don't really
like colons in local filenames.

$ touch a b c

$ tar -cf 't:a:r.tar' a b c
tar: Cannot execute remote shell: No such file or directory
tar: t\:a\:r.tar: Cannot open: Input/output error
tar: Error is not recoverable: exiting now
$ touch a b c; tar cf - >'t:a:r.tar'
a b c

$ echo -e 'a\nb\nc'| cpio --verbose --create -O c:p:i:o.cpio 
ssh: c: Name or service not known
cpio: c:p:i:o.cpio: Input/output error
$ echo -e 'a\nb\nc'| cpio --create > c:p:i:o.cpio 
cpio: a: truncating inode number
cpio: b: truncating inode number
cpio: c: truncating inode number
1 block

$ ls
a  b  c  c:p:i:o.cpio  t:a:r.tar

At Tue, 20 Dec 2016 21:05:14 +0000 Richard Kettlewell <invalid@invalid.invalid> wrote:

> 
> Robert Heller <heller@deepsoft.com> writes:
> > With the advent of point-and-click GUIs, filenames with spaces became 
> > possible.  For the most part (until really recently), old school UNIX users 
> > had become used to filenames without spaces and have come up with various 
> > space alternitives (dashes, underscores, camel case, etc.) and mostly 
> > continuted to do that, even with GUI interfaces.  Non-UNIX users (MacOS, 
> > MS-Windows), did not have any CLI history and and are more natrual-language 
> > oriented and use spaces, etc. with abandon.
> 
> The early Windows users were basically all MSDOS users.  I don’t think
> the cultural-historical argument works for them.

Until M$ started copycatting Apple...

> 

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                                                                                          

On 2016-12-20 22:05, Richard Kettlewell wrote:

>> Non-UNIX users (MacOS, 
>> MS-Windows), did not have any CLI history and and are more natrual-language 
>> oriented and use spaces, etc. with abandon.
> 
> The early Windows users were basically all MSDOS users.  I don’t think
> the cultural-historical argument works for them.

And there were MsDOS programs with menus and dialog boxes prior to
Windows. You could try to write names with spaces, but there was a
validate function that would reject the name.

The starting point for Windows users was not Windows itself, but the
Long Name capability for FAT (LFN). Prior to that file names were
limited to 8 chars, so nobody wasted a space in there. Yes, you could
actually create a filename with a space in there... but not easily.

-- 
Cheers,
       Carlos E.R.

On 2016-12-20 02:59, Rich wrote:

>   mv "Stupid Ass Filename.doc" "Stupid Ass Filename.pdf".
> 
> Yep, they actually think that by simply changing the name, that what
> was a doc before is now, by magic, a pdf.

No, they don't. They know that changing the extension will make the
system _try_ to open the file with the default PDF reader.

-- 
Cheers,
       Carlos E.R.

On 2016-12-21, Carlos E. R. <robin_listas@invalid.es> wrote:

> On 2016-12-20 22:05, Richard Kettlewell wrote:
>
>>> Non-UNIX users (MacOS, 
>>> MS-Windows), did not have any CLI history and and are more natrual-language 
>>> oriented and use spaces, etc. with abandon.
>> 
>> The early Windows users were basically all MSDOS users.  I don’t think
>> the cultural-historical argument works for them.

That depends.  There are probably a number of people whose first encounter
with computers was Windows 3.1.

> And there were MsDOS programs with menus and dialog boxes prior to
> Windows. You could try to write names with spaces, but there was a
> validate function that would reject the name.
>
> The starting point for Windows users was not Windows itself, but the
> Long Name capability for FAT (LFN).

And what a terrible hack that was^H^H^His.  But c'mon, admit it, many
of you no doubt accessed "Really Stupid Long Filename.doc" by typing
REALLY~1.DOC.

> Prior to that file names were limited to 8 chars, so nobody wasted
> a space in there. Yes, you could actually create a filename with a
> space in there... but not easily.

Ah, memories of tweaking a floppy disk's FAT with a disk zapper...

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

At 21 Dec 2016 01:26:26 GMT Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

> 
> On 2016-12-21, Carlos E. R. <robin_listas@invalid.es> wrote:
> 
> > On 2016-12-20 22:05, Richard Kettlewell wrote:
> >
> >>> Non-UNIX users (MacOS, 
> >>> MS-Windows), did not have any CLI history and and are more natrual-language 
> >>> oriented and use spaces, etc. with abandon.
> >> 
> >> The early Windows users were basically all MSDOS users.  I don’t think
> >> the cultural-historical argument works for them.
> 
> That depends.  There are probably a number of people whose first encounter
> with computers was Windows 3.1.
> 

And even more whose first encounter was Win 95, Win 97 or even Win ME or Win 
2000.

> > And there were MsDOS programs with menus and dialog boxes prior to
> > Windows. You could try to write names with spaces, but there was a
> > validate function that would reject the name.
> >
> > The starting point for Windows users was not Windows itself, but the
> > Long Name capability for FAT (LFN).
> 
> And what a terrible hack that was^H^H^His.  But c'mon, admit it, many
> of you no doubt accessed "Really Stupid Long Filename.doc" by typing
> REALLY~1.DOC.
> 
> > Prior to that file names were limited to 8 chars, so nobody wasted
> > a space in there. Yes, you could actually create a filename with a
> > space in there... but not easily.
> 
> Ah, memories of tweaking a floppy disk's FAT with a disk zapper...
> 

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                                                        

On 20/12/16 23:05, Richard Kettlewell wrote:
> Robert Heller <heller@deepsoft.com> writes:
>> With the advent of point-and-click GUIs, filenames with spaces became
>> possible.  For the most part (until really recently), old school UNIX users
>> had become used to filenames without spaces and have come up with various
>> space alternitives (dashes, underscores, camel case, etc.) and mostly
>> continuted to do that, even with GUI interfaces.  Non-UNIX users (MacOS,
>> MS-Windows), did not have any CLI history and and are more natrual-language
>> oriented and use spaces, etc. with abandon.
>
> The early Windows users were basically all MSDOS users.  I don’t think
> the cultural-historical argument works for them.
>
DOS was 6.3 chars IIRC and that was that.

a hangover from CP/M which go it from an Intel dev system IIRC.

I.e. long filenames appeared AFTER Windows.

On Wednesday 21 December 2016 06:05, The Natural Philosopher conveyed 
the following to comp.os.linux.misc...

> On 20/12/16 23:05, Richard Kettlewell wrote:
>
>> Robert Heller <heller@deepsoft.com> writes:
>>
>>> With the advent of point-and-click GUIs, filenames with spaces
>>> became possible.  For the most part (until really recently), old
>>> school UNIX users had become used to filenames without spaces and
>>> have come up with various space alternitives (dashes, underscores,
>>> camel case, etc.) and mostly continuted to do that, even with GUI
>>> interfaces.  Non-UNIX users (MacOS, MS-Windows), did not have any
>>> CLI history and and are more natrual-language oriented and use
>>> spaces, etc. with abandon.
>>
>> The early Windows users were basically all MSDOS users.  I don’t
>> think the cultural-historical argument works for them.
>>
> DOS was 6.3 chars IIRC and that was that.

8.3 characters, and no distinction between upper- and lowercase.  You 
could use lowercase, but internally it was all translated to all-
uppercase.

> a hangover from CP/M which go it from an Intel dev system IIRC.

I'm not sure on the Intel connection, but yes, CP/M also used an 8.3 
file name notation, and the .3 was used as an indicator of the file type 
─ i.e. whether it was executable or not.  And that's because the 
FAT filesystem does not support any UNIX-/POSIX-style permissions and 
ownerships.

This is also where the concept of "an extension" comes from.  In UNIX, 
whatever follows the period in a file name is not "an extension", but 
simply part of the file name, given that a UNIX file name can contain 
any number of periods and they can be put anywhere in the file name.  
(The original UNIX file name length was limited to 14 characters, 
though, including the period(s).)

Either way, CP/M ─ and DOS as its "successor" ─ needed some way to 
indicate whether a file was an executable or not, and so the idea of a 
maximum 8-character file name with a 3-character "extension" was 
conceived.  Personally I refer to that as a "suffix", because it doesn't 
"extend" anything ─ it's just part of the name of the file. 

> I.e. long filenames appeared AFTER Windows.

I'm not sure but I think they may have already been supported in Novell 
DOS 7 ─ at least, on a FAT filesystem, and using the same trick that 
Windows 95 would come to use later on.  Long file names were either way 
already supported in OS/2 when, but only when used with the HPFS 
filesystem ─ HPFS was also case-retentive, but not case-sensitive, 
similar to Microsoft's NTFS and Apple's HFS+.

The first Windows version to support long file names was Windows NT 3.1, 
but that was of course also on NTFS ─ it could also run off of FAT16, 
but then it didn't support long file names.  For the DOS-based Windows 
versions, the long file names were introduced with Windows 95, if 
I remember correctly.

-- 
= Aragorn =

On 21/12/16 07:52, Aragorn wrote:
> On Wednesday 21 December 2016 06:05, The Natural Philosopher conveyed
> the following to comp.os.linux.misc...
>
>> On 20/12/16 23:05, Richard Kettlewell wrote:
>>
>>> Robert Heller <heller@deepsoft.com> writes:
>>>
>>>> With the advent of point-and-click GUIs, filenames with spaces
>>>> became possible.  For the most part (until really recently), old
>>>> school UNIX users had become used to filenames without spaces and
>>>> have come up with various space alternitives (dashes, underscores,
>>>> camel case, etc.) and mostly continuted to do that, even with GUI
>>>> interfaces.  Non-UNIX users (MacOS, MS-Windows), did not have any
>>>> CLI history and and are more natrual-language oriented and use
>>>> spaces, etc. with abandon.
>>>
>>> The early Windows users were basically all MSDOS users.  I don’t
>>> think the cultural-historical argument works for them.
>>>
>> DOS was 6.3 chars IIRC and that was that.
>
> 8.3 characters, and no distinction between upper- and lowercase.  You
> could use lowercase, but internally it was all translated to all-
> uppercase.
>
>> a hangover from CP/M which go it from an Intel dev system IIRC.
>
> I'm not sure on the Intel connection, but yes, CP/M also used an 8.3
> file name notation, and the .3 was used as an indicator of the file type
> ─ i.e. whether it was executable or not.  And that's because the
> FAT filesystem does not support any UNIX-/POSIX-style permissions and
> ownerships.
>
> This is also where the concept of "an extension" comes from.  In UNIX,
> whatever follows the period in a file name is not "an extension", but
> simply part of the file name, given that a UNIX file name can contain
> any number of periods and they can be put anywhere in the file name.
> (The original UNIX file name length was limited to 14 characters,
> though, including the period(s).)
>
> Either way, CP/M ─ and DOS as its "successor" ─ needed some way to
> indicate whether a file was an executable or not, and so the idea of a
> maximum 8-character file name with a 3-character "extension" was
> conceived.  Personally I refer to that as a "suffix", because it doesn't
> "extend" anything ─ it's just part of the name of the file.
>
>> I.e. long filenames appeared AFTER Windows.
>
> I'm not sure but I think they may have already been supported in Novell
> DOS 7 ─ at least, on a FAT filesystem, and using the same trick that
> Windows 95 would come to use later on.  Long file names were either way
> already supported in OS/2 when, but only when used with the HPFS
> filesystem ─ HPFS was also case-retentive, but not case-sensitive,
> similar to Microsoft's NTFS and Apple's HFS+.
>
> The first Windows version to support long file names was Windows NT 3.1,
> but that was of course also on NTFS ─ it could also run off of FAT16,
> but then it didn't support long file names.

Oh yes, we all remember THE_DA~1.TXT type of files...

 >  For the DOS-based Windows
> versions, the long file names were introduced with Windows 95, if
> I remember correctly.
>
That accords pretty much with my recollection.

The INTEL development system was something like an INTELLEC 80 IIRC. Not 
sure whether it had a disc system.

I have it in my not necessarily correct memory that early INTEL 
development systems featured floppy disc drives, and the format was 
copied from those.

On 2016-12-21, Aragorn <thorongil@telenet.be> wrote:
> I'm not sure on the Intel connection, but yes, CP/M also used an 8.3 
> file name notation...

CP/M was patterned after DEC operating systems, particularly OS/8,
although OS/8 filenames were limited to 6.2. (PIP actually first saw
the light of day on the PDP-6 in the 1960s.)

-- 
-----------------------------------------------------------------------------
  Roger Blake (Posts from Google Groups killfiled due to excess spam.)

  NSA sedition and treason        -- http://www.DeathToNSAthugs.com
  Don't talk to cops!             -- http://www.DontTalkToCops.com
  Badges don't grant extra rights -- http://www.CopBlock.org
-----------------------------------------------------------------------------

On 2016-12-21, Aragorn <thorongil@telenet.be> wrote:

> On Wednesday 21 December 2016 06:05, The Natural Philosopher conveyed 
> the following to comp.os.linux.misc...
>
>> DOS was 6.3 chars IIRC and that was that.
>
> 8.3 characters, and no distinction between upper- and lowercase.  You 
> could use lowercase, but internally it was all translated to all-
> uppercase.
>
>> a hangover from CP/M which go it from an Intel dev system IIRC.
>
> I'm not sure on the Intel connection, but yes, CP/M also used an 8.3 
> file name notation, and the .3 was used as an indicator of the file
> type ─ i.e. whether it was executable or not.  And that's because the 
> FAT filesystem does not support any UNIX-/POSIX-style permissions and 
> ownerships.

Another bit of cruft inherited from CP/M was that 0x1A character that
sometimes still appears at the end of text files.  The CP/M file system
stored the size of the file as a number of 128-byte sectors, not the
actual number of bytes (presumably to conserve scarce directory space).
The last sector of a text file was padded with 0x1A, which was taken as
an end-of-file flag.  The MS-DOS FAT file system, on the other hand,
stores the size of a file in bytes, making the 0x1A unnecessary.  But,
in the name of putting the "backward" in "backward compatibility",
it tagged along, causing all sorts of grief to this day.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

On 2016-12-21 02:26, Charlie Gibbs wrote:
> On 2016-12-21, Carlos E. R. <> wrote:
> 
>> On 2016-12-20 22:05, Richard Kettlewell wrote:
>>
>>>> Non-UNIX users (MacOS, 
>>>> MS-Windows), did not have any CLI history and and are more natrual-language 
>>>> oriented and use spaces, etc. with abandon.
>>>
>>> The early Windows users were basically all MSDOS users.  I don’t think
>>> the cultural-historical argument works for them.
> 
> That depends.  There are probably a number of people whose first encounter
> with computers was Windows 3.1.

Well... You had actually to boot MsDOS, then start windows manually, by
typing the name. Yes, you might write that in to autoexec.

> 
>> And there were MsDOS programs with menus and dialog boxes prior to
>> Windows. You could try to write names with spaces, but there was a
>> validate function that would reject the name.
>>
>> The starting point for Windows users was not Windows itself, but the
>> Long Name capability for FAT (LFN).
> 
> And what a terrible hack that was^H^H^His.  But c'mon, admit it, many
> of you no doubt accessed "Really Stupid Long Filename.doc" by typing
> REALLY~1.DOC.

Well... no. Unless you count those transitional programs that were not
aware of LFNs and only displayed the short name.

There were GUIs and TUIs. No need to type those names. :-P


>> Prior to that file names were limited to 8 chars, so nobody wasted
>> a space in there. Yes, you could actually create a filename with a
>> space in there... but not easily.
> 
> Ah, memories of tweaking a floppy disk's FAT with a disk zapper...

PC Tools ;-)

A trick was to use a raw disk editor to insert an unprintable char into
an 8 byte file name. Like an space, a return... there was no way to
enter that name in the CLI or dialogs.


-- 
Cheers,
       Carlos E.R.

On 2016-12-21 06:52, Aragorn wrote:
> On Wednesday 21 December 2016 06:05, The Natural Philosopher conveyed 
> the following to comp.os.linux.misc...

>> I.e. long filenames appeared AFTER Windows.
> 
> I'm not sure but I think they may have already been supported in Novell 
> DOS 7 ─ at least, on a FAT filesystem, and using the same trick that 
> Windows 95 would come to use later on.  Long file names were either way 
> already supported in OS/2 when, but only when used with the HPFS 
> filesystem ─ HPFS was also case-retentive, but not case-sensitive, 
> similar to Microsoft's NTFS and Apple's HFS+.
> 
> The first Windows version to support long file names was Windows NT 3.1, 
> but that was of course also on NTFS ─ it could also run off of FAT16, 
> but then it didn't support long file names.  For the DOS-based Windows 
> versions, the long file names were introduced with Windows 95, if 
> I remember correctly.

I think, but I can't verify at the moment, that msdos 6 had some support
for long names.

-- 
Cheers,
       Carlos E.R.

Robert Heller <heller@deepsoft.com> wrote:

> scp foo:bar otherhost:destdir/
> 
> where 'foo:bar' is just a local file name.  Opps...  

scp ./foo:bar otherhost:destdir/


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
> On 2016-12-21, Carlos E. R. <robin_listas@invalid.es> wrote:
>> On 2016-12-20 22:05, Richard Kettlewell wrote:
>>>> Non-UNIX users (MacOS, MS-Windows), did not have any CLI history
>>>> and and are more natrual-language oriented and use spaces,
>>>> etc. with abandon.
>>> 
>>> The early Windows users were basically all MSDOS users.  I don’t think
>>> the cultural-historical argument works for them.
>
> That depends.  There are probably a number of people whose first
> encounter with computers was Windows 3.1.

Depends on what?  Those users were not ‘the early Windows users’.  It
had been around more than half a decade by that point.

-- 
http://www.greenend.org.uk/rjk/

On 12/23/2016 01:38 PM, Richard Kettlewell wrote:
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>> On 2016-12-21, Carlos E. R. <robin_listas@invalid.es> wrote:
>>> On 2016-12-20 22:05, Richard Kettlewell wrote:
>>>>> Non-UNIX users (MacOS, MS-Windows), did not have any CLI history
>>>>> and and are more natrual-language oriented and use spaces,
>>>>> etc. with abandon.
>>>>
>>>> The early Windows users were basically all MSDOS users.  I don’t think
>>>> the cultural-historical argument works for them.
>>
>> That depends.  There are probably a number of people whose first
>> encounter with computers was Windows 3.1.
>
> Depends on what?  Those users were not ‘the early Windows users’.  It
> had been around more than half a decade by that point.
>
	Yes it had been around but not particularly usable until
3..  I forget the exact number but 3.1 really was the one promoted
and which began to take over from the older CPM and MS/PC-DOS
installations.  3.1 users were early users of productive Windows
versions.

	I myself was using a CBM-128/34 and had used it with GEOS
which gave me plenty of experience to help the girl down the hall
using Windows 3.1.  It also gave me enough experience of 3.1 to
spend my spare change on an Amiga 1000 as CBM was trying to
get all the early adopters to switch to the A500 or A2000 which
permitted an more advanced internal architecture with larger
memory for audio and video.

	bliss

-- 
bliss dash SF 4 ever at dslextreme dot com

On 12/23/2016 05:16 PM, Bobbie Sellers wrote:
> On 12/23/2016 01:38 PM, Richard Kettlewell wrote:
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>>> On 2016-12-21, Carlos E. R. <robin_listas@invalid.es> wrote:
>>>> On 2016-12-20 22:05, Richard Kettlewell wrote:
>>>>>> Non-UNIX users (MacOS, MS-Windows), did not have any CLI history
>>>>>> and and are more natrual-language oriented and use spaces,
>>>>>> etc. with abandon.
>>>>>
>>>>> The early Windows users were basically all MSDOS users.  I don’t think
>>>>> the cultural-historical argument works for them.
>>>
>>> That depends.  There are probably a number of people whose first
>>> encounter with computers was Windows 3.1.
>>
>> Depends on what?  Those users were not ‘the early Windows users’.  It
>> had been around more than half a decade by that point.
>>
> 	Yes it had been around but not particularly usable until
> 3..  I forget the exact number but 3.1 really was the one promoted
> and which began to take over from the older CPM and MS/PC-DOS
> installations.  3.1 users were early users of productive Windows
> versions.
>

3.11 is where it started to become useful.


> 	I myself was using a CBM-128/34 and had used it with GEOS
> which gave me plenty of experience to help the girl down the hall
> using Windows 3.1.  It also gave me enough experience of 3.1 to
> spend my spare change on an Amiga 1000 as CBM was trying to
> get all the early adopters to switch to the A500 or A2000 which
> permitted an more advanced internal architecture with larger
> memory for audio and video.
>
> 	bliss
>


-- 
Caver1

On 2016-12-22, Carlos E. R. <robin_listas@invalid.es> wrote:

> On 2016-12-21 02:26, Charlie Gibbs wrote:
>
>> On 2016-12-21, Carlos E. R. <> wrote:
>> 
>>> On 2016-12-20 22:05, Richard Kettlewell wrote:
>>>
>>>>> Non-UNIX users (MacOS, MS-Windows), did not have any CLI history and
>>>>> and are more natrual-language oriented and use spaces, etc. with abandon.
>>>>
>>>> The early Windows users were basically all MSDOS users.  I don’t think
>>>> the cultural-historical argument works for them.
>> 
>> That depends.  There are probably a number of people whose first encounter
>> with computers was Windows 3.1.
>
> Well... You had actually to boot MsDOS, then start windows manually, by
> typing the name. Yes, you might write that in to autoexec.

Oh, I remember now.  Yes, the autoexec.bat trick would be preferable
when setting up a system for J. Random Luser.  As for the rest of us,
some of us couldn't stand typing "win", so we made up a LOSE.BAT which
allowed us to type a more appropriate command.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!