datetime issue

[Kushal Kumaran]

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.

It's a readline thing, when you've configured it to use emacs
keybindings. You can look at the emacs manual about the quoted-insert
function if you want. It's useful in emacs because people like to bind
ordinary keystrokes to do esoteric stuff (such as binding the TAB key to
insert appropriate amount of spaces), which means that you need a way to
override it (if you want to insert a literal TAB character, for
example).

 

[Grant Edwards]

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.

And even people who have been writing bourne/korn/bash shell sripts
for 30 years (crap, I'm old...) still occasionally (or even regularly)
fall into the "spaces in filenames hole". It's just too easy to type
$Var instead of "$Var".

And not setting the "nounset" option can result in hours of fun trying
to find that one place where a variable name is mistyped...

It would be astonishing if an experienced, competent bash
programmer couldn't write an installation tool in bash.

Indeed. But when the good folks at RedHat sat down to write an
installation tool back in '95 or so, they chose Python.

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.

That's not really helping your argument, since RedHat's install
scripts have been written in Pyton since forever...

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.

I think anybody who writes anything of substance in bash would have to
agree. However when the task involves mainly manipulating files and
running other programs, the clumsy control structures are a small
enough price to pay for the ease with which bash deals with
manipulating files/paths/programs.

OTOH, you can use C shell or PHP and get the worst of both worlds...

 

[Hans Mulder]

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.

How does that trick work? If I need a control character
that is not available in my current keyboard mapping, how
would I enter such a character using this Ctrl-Q trick?


Just wondering,

-- HansM

 

[Thomas Rachel]

Am 31.10.2012 06:39 schrieb Robert Miles:

For those of you running Linux: You may want to look into whether
NoCeM is compatible with your newsreader and your version of Linux.

This sounds as if it was intrinsically impossible to evaluate NoCeMs in
Windows.

If someone writes a software for it, it can be run wherever desired.


Thomas

 

[Steven D'Aprano]

How does that trick work? If I need a control character that is not
available in my current keyboard mapping, how would I enter such a
character using this Ctrl-Q trick?

This only works if you are running a Linux or Unix shell with the
libreadline library installed. This should work on nearly any modern
Linux system with the bash shell. I don't know about other shells.

On Mac OS, the relevant library is called libedit instead, and the
details may be different.

On Windows, you're out of luck.

Anyway, using Linux and bash: at the shell, if I type Ctrl-U, that is
interpreted by the shell to mean "clear the line currently being edited".
So if I type Ctrl-U, the line is cleared.

But if I type Ctrl-Q first, then Ctrl-U, instead readline enters a
literal ^U character (ASCII value 0x15 = NAK Negative AcKnowledgment)
into the line editing buffer.

The same trick should work in the Python interactive editor:
21


Note that this may or may not work in IDEs such as IDLE. Many IDEs do
their own thing for editing, and there's no guarantee they will support
this functionality.

One last comment: readline is very configurable, and the command to
insert the next character could be just about anything. But Ctrl-Q is the
standard.

 

[Hans Mulder]

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

Actually, the correct name for this character is OS-dependant:
The ASCII standard prescribes that if an OS chooses to use a
single character as its line terminator, then it must be this
one, and one should call it "newline". Otherwise, it's name
is "linefeed". So, the correct name is "newline" on Posix
system, but "linefeed" on Windows.

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.

It depends on what mode bash is in. In Emacs mode, C-q works as you
describe, but in Vi mode you'd use C-v.

Doesn't everybody run bash in Vi mode :-?

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

Another quirk is that on most keyboards the "enter" key generates a
Carriage Return, which the terminal driver than converts to a Newline,
if icrlf mode is active. (Shouldn't that be called "icrnl" mode?)


Hope this helps,

-- HansM

 

[Steven D'Aprano]

On 7/11/12 01:13:47, Steven D'Aprano wrote:

Actually, the correct name for this character is OS-dependant: The ASCII
standard prescribes that if an OS chooses to use a single character as
its line terminator, then it must be this one, and one should call it
"newline". Otherwise, it's name is "linefeed". So, the correct name is
"newline" on Posix system, but "linefeed" on Windows.

I find that hard to believe. Do you have a source for this claim?

The ASCII standard has nothing to do with operating systems. It is a
character encoding system, whether you are using computers or notches
carved into pieces of wood, you can encode characters to values using
ASCII. ASCII is operating system agnostic.

Every source I have found describing the ASCII standard, and its
equivalents from other standards bodies (e.g. ISO/IEC 646, EMCA 6) either
directly refer to chr 10 as LF/Linefeed or refer back to the C0 control
codes, which refers to it as LF/Linefeed.

For example:

http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-006.pdf

See also:

http://www.terena.org/activities/multiling/euroml/section04.html

which clearly shows char 10 as LF in all the given ISO 646 variants.

If you have a source for this claim, I would like to see it, otherwise I
will stand by my claim that the standard name for ASCII char 10 is
"linefeed".