datetime issue

[rusi]

My filenames seldom have spaces in them, but that has nothing to do
with how I write English. Names are names. They're not essays, they
are not written as full sentences. When a name contains spaces, it
must be delimited (or the space must be escaped, if your environment
permits) any time it occurs inside some other context - most commonly,
as a command-line argument.

Back when I was using MS-DOS 5, it was possible to have file names
with spaces. It wasn't easy to manipulate them from the command line,
but you could reference them using globs (eg replace the space(s) with
? and hope that there are no false hits). OS/2, when working on a FAT
filesystem, would create files called "EA DATA. SF" or "WP ROOT. SF"
or "WP SHARE. SF" (two spaces in each), and most DOS/Windows programs
wouldn't (couldn't) touch them - they were safe repositories for
system metadata (on smarter filesystems, that sort of thing would be
stored as file attributes, not as separate files).

It's nothing to do with operating system. File names are names, and
spaces in them are seldom worth the hassle unless you manipulate those
files solely using a GUI.

ChrisA

So you and I (and probably many on this list) agree!

 

[Roy Smith]

It's nothing to do with operating system. File names are names, and
spaces in them are seldom worth the hassle unless you manipulate those
files solely using a GUI.

That's a very ascii-esqe attitude. In a fully unicode world, I could
easily see using U+00A0 (NO-BREAK SPACE) in file names, and still have
space-delimited CLI work just fine.

But, yeah, in the world we live in today, I try to avoid spaces in
filenames. But, instead of turning "My File Name" into MyFileName, I'll
usually do it as My-File-Name or My_File_Name.

 

[Chris Angelico]

That's a very ascii-esqe attitude. In a fully unicode world, I could
easily see using U+00A0 (NO-BREAK SPACE) in file names, and still have
space-delimited CLI work just fine.

Oh, do you have a "U+00A0-bar" on your keyboard?

ChrisA

 

[Grant Edwards]

That's a very ascii-esqe attitude. In a fully unicode world, I could
easily see using U+00A0 (NO-BREAK SPACE) in file names, and still have
space-delimited CLI work just fine.

No, it wouldn't work just fine. You'd never know when looking at
names whether it was a "regular" space or a "no-break space", and
names would be visually ambiguous. Visually ambiguous names are
horrible.

 

[Dennis Lee Bieber]

It's nothing to do with operating system. File names are names, and
spaces in them are seldom worth the hassle unless you manipulate those
files solely using a GUI.

At least spaces are visible.

CP/V would accept non-printable characters in file names... Things
like BEL were valid -- but figure out where in the name the BEL
character was when listing the directory contents <G>

{Dropping into the BASIC interpreter did make it easier -- if the
name had non-printable characters, it would display the entire name in
EBCDIC}

 

[Grant Edwards]

At least spaces are visible.

CP/V would accept non-printable characters in file names... Things
like BEL were valid -- but figure out where in the name the BEL
character was when listing the directory contents <G>

Don't most OSes allow non-printing characters in filenames? VMS and
Unix always have. AFAIK, there are only two characters that can't
appear in a Unix filename: '\x00' and '/'.

 

[rurpy]

/ (e-mail address removed) wrote on Fri 2.Nov'12 at 11:39:10 -0700 /


No, i'm not a "troll". I was just adding my opinion to the thread, I
assumed that was allowed. I didn't say UNIX is better than Windows,
did I; I just feel that Windows is not -- for me anyway -- the most
suitable plaform for learning about the science of computing and
coding, etc... being a computer science student that's the view i
have and share with those I learn with and from. Why must people be
accused of trolling everytime they make a statement that conveys a
preference over one platform or language, for example, than the
other. Provoking someone by labeling them a troll or implying they
might be is a bit childish really.

I deliberately worded my response to avoid calling you a
troll but rather just suggested the possibility so a denial
without all the indignation would be more appropriate.
(And FWIW I agree that "troll" is often used here synonymously
with "I disagree with you" but that is not how I used it.)

You should realize that a good way to start an endless argument
and one that has a long history of being used by trolls is to
assert that OS/language/whatever is "better" than some other
one in an environment where there are also lots of users of the
other one. Substituting "serious" or any other value-laden,
unsubstantiatable word for "better" is just a insignificant
variation.

 

[Dennis Lee Bieber]

Don't most OSes allow non-printing characters in filenames? VMS and
Unix always have. AFAIK, there are only two characters that can't
appear in a Unix filename: '\x00' and '/'.

But can you /enter/ them with common keystrokes on a plain text
terminal (it's been 35 years, so I don't recall the exact key used for
the BEL on CP/V -- my mind thinks <ctrl-f> was used)... No cut&paste
from "character map", no <alt>-3digitsequence...

 

[Steven D'Aprano]

But can you /enter/ them with common keystrokes on a plain text
terminal (it's been 35 years, so I don't recall the exact key used for
the BEL on CP/V -- my mind thinks <ctrl-f> was used)... No cut&paste
from "character map", no <alt>-3digitsequence...

For most people, that's a pointless restriction. You might as well insist
that the file name can be typed without using the shift key, or using
only the left hand of the keyboard. Copy-paste, char map, alt-digits are
as much a part of the input environment on modern systems as the keyboard.

Nevertheless, I do tend to prefer underscores to spaces, simply because I
often use naive tools that treat spaces as separators. That is, command
line shells.

For what it's worth, you can enter any control character in Unix/Linux
systems with readline in bash using the C-q key combination. Newline
needs a bit of special treatment: you need to wrap the name in single
quotes to stop the newline from being interpreted as the end of the
command.

[steve@ando temp]$ touch 'foo
bar'

To enter the newline, I typed Ctrl-Q to tell bash to treat the next
character as a literal, and then typed Ctrl-J to get a newline.

[steve@ando temp]$ ls
foo?bar
[steve@ando temp]$ python -c "import os

for nm in os.listdir('.'): print repr(nm)"

'foo\nbar'

 

[Steven D'Aprano]

My filenames seldom have spaces in them, but that has nothing to do with
how I write English. Names are names. They're not essays, they are not
written as full sentences.

But names are often multiple words and sentence fragments, and for those
you *need* spaces. Or at least an ersatz space, like underscore, which is
ugly and harder to use, but at least makes using command shells easier to
use. But don't be fooled: the fault belongs to the shell, not the space.

The problem is that shells are untyped and treat *everything* as a stream
of text, and therefore cannot distinguish between arguments, variables,
numbers, commands, etc. except by a few simplistic conventions such as:

"The first word on the line is the command."
"If it starts with a dash, it must be a command option."
"Arguments are separated by spaces."
etc.

When your data (e.g. filenames) violate those naive assumptions, as they
frequently do, the shell cannot cope. One solution would be to fix the
tools. Another would be to mangle the data.

"Real" programming languages don't have this problem. You can trivially
refer to any file name, regardless of the characters in its name, in
Python because you have a much more powerful set of tools: commands take
real arguments, and the presence of a space in one argument cannot cause
it to "bleed over" into the next argument.

The downside is that if spaces are not argument separators, then you need
something else to be an argument separator. Or you need argument
delimiters. Or strings need to be quoted. Programming languages do these
things because they are designed to be correct. Shell do not because they
are designed for lazy users and merely aim to be "good enough".

 

[Roy Smith]

Shell do not [quote strings, etc] because they
are designed for lazy users and merely aim to be "good enough".

Well, sort of. Or, perhaps more correctly, "Yes, but that's a good
thing".

Shells are designed to be interactive tools, where most commands get run
once and thrown away. As such, you want everything to be easy to type,
which largely means your fingers never leave the main part of the
keyboard and you never have to reach for the shift key.

The basic unix shell syntax was laid down in the days of the ASR-33. It
was slow, hard to type on, and only had a single case of the alphabet
(and missing a few pieces of punctuation). Saving keystrokes was an
important consideration.

Programming languages are designed to write programs. Not only will the
code be {used, read, maintained} for a much longer period of time, it
will be used by people other than the original author, and on inputs
other than originally intended. It needs to be more robust.

The problem is that shells got pressed into service as programming
languages. At that, they suck. Sure, putting a few commands into a
file for reuse was great. Adding a few bells and whistles like
variables and conditional execution added greatly to the power of the
tool. But, by the time we got to 100 (or 1000!) line shell scripts with
functions, loops, arithmetic, etc, things had clearly gone off into the
weeds. It's just the wrong tool for that.

 

[Prasad, Ramit]

No, it wouldn't work just fine. You'd never know when looking at
names whether it was a "regular" space or a "no-break space", and
names would be visually ambiguous. Visually ambiguous names are
horrible.

Not to mention that in the GUI I (usually) want the space to be a
"break space".



~Ramit


This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy andcompleteness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.

 

[Prasad, Ramit]

On Mon, 05 Nov 2012 14:47:47 -0500, Dennis Lee Bieber wrote:

[snip]

Nevertheless, I do tend to prefer underscores to spaces, simply because I
often use naive tools that treat spaces as separators. That is, command
lineshells.

I visually prefer spaces but it is easier to work with underscores.
Thankfully there are plenty of command line utilities for pattern
renaming that let me shift to and from spaces as necessary.

For what it's worth, you can enter any control character in Unix/Linux
systems with readline in bash using the C-q key combination. Newline
needs a bit of special treatment: you need to wrap the name in single
quotes to stop the newline from being interpreted as the end of the
command.

[steve@ando temp]$ touch 'foo
bar'

To enter the newline, I typed Ctrl-Q to tell bash to treat the next
character as a literal, and then typed Ctrl-J to get a newline.

That sounds complicated, my version of bash lets me type
'foo<enter>bar'<enter> for the same effect.


~Ramit


This email is confidential and subject to important disclaimers and
conditions including on offersfor the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.

 

[Steven D'Aprano]

That sounds complicated, my version of bash lets me type
'foo<enter>bar'<enter> for the same effect.

Well, I learned something new about bash.

On the other hand, the Ctrl-Q next-char-is-literal trick works for
entering control characters that otherwise don't have a key on the
keyboard.

 

[Prasad, Ramit]

Well, I learned something new about bash.

On the other hand, the Ctrl-Q next-char-is-literal trick worksfor
entering control characters that otherwise don't have a key on the
keyboard.

Would you mind elaborating on howthis works? I know it's not a bash
list, but I do not understand how ctrl-J is considered a literal.
Obviously, I must have a different definition of "literal". Where
can I find a list of other literals? My Google-fu is being weak
today.


~Ramit


This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.

 

[Steven D'Aprano]

I have just finished a 251 line bash shell script that builds my linux
distro from scratch.

"From scratch"? So if you run it on bare metal with no OS, it works?



But seriously -- bash is a mature, powerful shell. It works well for what
it does. It has been designed to make it easy[1] to automate system admin
tasks. It would be astonishing if an experienced, competent bash
programmer couldn't write an installation tool in bash. By comparison,
few general purpose programming languages (with the obvious exception of
perl) are designed for system administration as their primary purpose.

But... how robust is your script? How many bugs does it contain? Chances
are you will only use it a handful of times, on the same system. That's
not a lot of testing to be sure that it is free of bugs, and robust
against unexpected input.

Hell, even widely used and distributed install scripts written by
companies with the resources of Ubuntu and Red Hat have a distressing
tendency to break. Or worse, to behave in unexpected ways.

Unless you are some sort of bash-scripting über-geek superhero with
powers beyond those of mortal men, chances are that your script is much
more buggy and fragile than you imagine. How well does it recover from
errors? Does it leave you with a broken system, half installed? How
easily can you maintain it after three months? Will it work in the
presence of filenames with newlines in them?



[1] For some definition of "easy". In my opinion, control structures like
"for" and "if" in bash are hard to use, hard to read, easy to get wrong,
give cryptic error messages when you do get them wrong, and are ugly.
Tests are obfuscated, and as always, the fact that everything is text in
bash means it is way harder than it needs to be to use rich, modern data
structures.

 

[Steven D'Aprano]

Would you mind elaborating on how this works? I know it's not a bash
list, but I do not understand how ctrl-J is considered a literal.
Obviously, I must have a different definition of "literal". Where can I
find a list of other literals? My Google-fu is being weak today.

I'm not an expert, so the following may not be exactly correct. As I
understand it, when you hit a key on the keyboard, it sends the character
you typed to the operating system. (The OS can then remap keys, generate
keyboard events including a timestamp, etc.)

Hit the J key, and the event includes character "j". Hit Shift-J, and
character "J" is sent. Hit Ctrl-J, and the character sent is the ASCII
control character ^J, or newline. (Technically, the name for ASCII 10 is
"linefeed" rather than "newline".)

Similarly, other control character combinations send other control codes:

^A = ASCII 0x01 Start Of Heading
^L = ASCII 0xFF Formfeed \f
^M = ASCII 0x0D Carriage Return \r

etc.

http://en.wikipedia.org/wiki/C0_and_C1_control_codes


When readline is enabled in bash, one of the standard editing commands is
that C-q (usually ctrl-Q on the keyboard) instructs readline to treat the
next key as a literal. So Ctrl-Q followed by Backspace won't delete the
previous character, but insert a literal DEL 0x7F character.

(One of those historical quirks is that on most(?) keyboards, the
Backspace key generates a DEL character rather than the ^H backspace
control code, and the Delete key generates an escape sequence. Go figure.)

 

[Gregory Ewing]

The downside is that if spaces are not argument separators, then you need
something else to be an argument separator. Or you need argument
delimiters. Or strings need to be quoted. Programming languages do these
things because they are designed to be correct. Shell do not because they
are designed for lazy users and merely aim to be "good enough".

That's overly judgemental. In the environment where shells originated,
not being able to easily put spaces in file names wasn't considered a
problem. File names weren't thought of as names in the natural language
sense, but as identifiers in the programming sense.

You don't complain that you can't put spaces in identifiers in a
Python program, do you? No, because that would require all identifiers
to be quoted somehow, which would drive you crazy. In the same way,
requiring all filenames to be quoted would drive shell users crazy.

 

[Roy Smith]

That's overly judgemental. In the environment where shells originated,
not being able to easily put spaces in file names wasn't considered a
problem. File names weren't thought of as names in the natural language
sense, but as identifiers in the programming sense.

You don't complain that you can't put spaces in identifiers in a
Python program, do you? No, because that would require all identifiers
to be quoted somehow, which would drive you crazy. In the same way,
requiring all filenames to be quoted would drive shell users crazy.

On the other hand, if you *wanted* to put a space in a Python
identifier, you just can't. If you want to put a space in a file name
in the shell, all you need do is put spaces around the name. Or, if you
prefer, escape the space with a backslash.

Oh, wait. This blows my mind...
['__doc__', '__module__', 'x y']

I did not expect this to work. Not quite sure what I've created here.

 

[Steven D'Aprano]

That's overly judgemental.

Judgemental, sure. Overly judgemental? Not in my opinion.

Besides, to some degree, all progress depends on the lazy person. It's
less work to have the computer do it than to do it yourself.

In the environment where shells originated,
not being able to easily put spaces in file names wasn't considered a
problem. File names weren't thought of as names in the natural language
sense, but as identifiers in the programming sense.

What you say may be true, but the question is, *why* did they think this?
The closest analogue to computer files are paper files, which have always
been treated as names in the natural language sense, and spaces allowed.

"Miss Jones, fetch me the Acme Television Company file!"

sort of thing. And this is exactly why people want spaces in file names,
and have to be trained or prevented from doing so. So why did early
shells ignore the (implied) business requirement that files represent
natural names and instead treat them as programming identifiers?

Because it was the easy thing to do.

You don't complain that you can't put spaces in identifiers in a Python
program, do you?

I would if I could. But that would require the language to be... smarter?
Less easy to use? *More* easy to use? It would require a major paradigm
shift, and so I don't expect to treat identifiers as names, and use
either CamelCase or names_with_underscores instead, even when the result
is ugly.

But that's not a fixed law of nature. If Inform 7 can include spaces in
identifiers, so could other languages.

http://www.ifwiki.org/index.php/Inform_7_for_Programmers/Part_1