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.
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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/
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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/
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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)
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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!
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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 =
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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/
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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?
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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. --
![]() |
0 |
![]() |
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/
![]() |
0 |
![]() |
--=-=-= 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----- --=-=-=--
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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? >
![]() |
0 |
![]() |
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... > >>
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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!
![]() |
0 |
![]() |
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!
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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/
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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?
![]() |
0 |
![]() |
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/
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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. > >:-) >
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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!
![]() |
0 |
![]() |
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!
![]() |
0 |
![]() |
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).
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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. > >
![]() |
0 |
![]() |
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!
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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/
![]() |
0 |
![]() |
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 ' >> >>> >
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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 *=+* >>> >>>> >>
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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.) > > >>>> >>>>> >>> >
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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/
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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!
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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 =
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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 -----------------------------------------------------------------------------
![]() |
0 |
![]() |
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!
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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.
![]() |
0 |
![]() |
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/
![]() |
0 |
![]() |
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/
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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!
![]() |
0 |
![]() |