Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #29263 > unrolled thread
| Started by | Νικόλαος Κούρας <nikos.gr33k@gmail.com> |
|---|---|
| First post | 2012-09-15 10:33 -0700 |
| Last post | 2012-09-15 12:26 -0700 |
| Articles | 20 on this page of 133 — 38 participants |
Back to article view | Back to comp.lang.python
datetime issue Νικόλαος Κούρας <nikos.gr33k@gmail.com> - 2012-09-15 10:33 -0700
Re: datetime issue Jason Friedman <jason@powerpull.net> - 2012-09-15 12:58 -0600
Re: datetime issue Chris Rebert <clp2@rebertia.com> - 2012-09-15 12:05 -0700
Re: datetime issue Νικόλαος Κούρας <nikos.gr33k@gmail.com> - 2012-09-15 12:26 -0700
Re: datetime issue MRAB <python@mrabarnett.plus.com> - 2012-09-15 21:28 +0100
Re: datetime issue Νικόλαος Κούρας <nikos.gr33k@gmail.com> - 2012-09-15 22:15 -0700
Re: datetime issue Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-09-16 01:53 -0400
Re: datetime issue Νικόλαος Κούρας <nikos.gr33k@gmail.com> - 2012-09-16 00:51 -0700
Re: datetime issue Νικόλαος Κούρας <nikos.gr33k@gmail.com> - 2012-09-16 01:18 -0700
Re: datetime issue Νικόλαος Κούρας <nikos.gr33k@gmail.com> - 2012-09-16 01:18 -0700
Re: datetime issue Νικόλαος Κούρας <nikos.gr33k@gmail.com> - 2012-09-16 00:51 -0700
Re: datetime issue Νικόλαος Κούρας <nikos.gr33k@gmail.com> - 2012-09-16 01:25 -0700
Re: datetime issue Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-16 09:53 +0000
Re: datetime issue Νικόλαος Κούρας <nikos.gr33k@gmail.com> - 2012-09-16 03:15 -0700
Re: datetime issue Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-16 10:49 +0000
Re: datetime issue Νικόλαος Κούρας <nikos.gr33k@gmail.com> - 2012-09-16 03:54 -0700
Re: datetime issue Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-16 11:34 +0000
Re: datetime issue Νικόλαος Κούρας <nikos.gr33k@gmail.com> - 2012-09-16 04:56 -0700
Re: datetime issue Dave Angel <d@davea.name> - 2012-09-16 15:31 -0400
Obnoxious postings from Google Groups (was: datetime issue) Ben Finney <ben+python@benfinney.id.au> - 2012-09-16 23:18 +1000
Re: Obnoxious postings from Google Groups (was: datetime issue) pandora.koura@gmail.com - 2012-09-16 08:41 -0700
Re: Obnoxious postings from Google Groups (was: datetime issue) Joel Goldstick <joel.goldstick@gmail.com> - 2012-09-16 11:57 -0400
Re: Obnoxious postings from Google Groups (was: datetime issue) pandora.koura@gmail.com - 2012-09-16 09:06 -0700
Re: Obnoxious postings from Google Groups (was: datetime issue) Joel Goldstick <joel.goldstick@gmail.com> - 2012-09-16 12:23 -0400
Re: Obnoxious postings from Google Groups (was: datetime issue) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-16 16:54 +0000
Re: Obnoxious postings from Google Groups Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-09-16 20:26 +0100
Re: Obnoxious postings from Google Groups (was: datetime issue) Gene Heskett <gheskett@wdtv.com> - 2012-09-16 12:32 -0400
Re: Obnoxious postings from Google Groups (was: datetime issue) pandora.koura@gmail.com - 2012-09-16 09:06 -0700
Re: Obnoxious postings from Google Groups Terry Reedy <tjreedy@udel.edu> - 2012-09-16 12:30 -0400
Re: Obnoxious postings from Google Groups (was: datetime issue) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-16 16:52 +0000
Re: Obnoxious postings from Google Groups Mayuresh Kathe <mayuresh@kathe.in> - 2012-09-17 01:09 +0530
Re: Obnoxious postings from Google Groups (was: datetime issue) Jamie Paul Griffin <jamie@kode5.net> - 2012-09-17 14:28 +0100
Re: Obnoxious postings from Google Groups (was: datetime issue) pandora.koura@gmail.com - 2012-09-16 08:44 -0700
Re: Obnoxious postings from Google Groups (was: datetime issue) Chris Angelico <rosuav@gmail.com> - 2012-09-17 01:57 +1000
Re: Obnoxious postings from Google Groups (was: datetime issue) pandora.koura@gmail.com - 2012-09-16 09:02 -0700
Re: Obnoxious postings from Google Groups (was: datetime issue) pandora.koura@gmail.com - 2012-09-16 09:02 -0700
Re: Obnoxious postings from Google Groups (was: datetime issue) Gene Heskett <gheskett@wdtv.com> - 2012-09-16 12:28 -0400
Re: Obnoxious postings from Google Groups Robert Miles <robertmiles@teranews.com> - 2012-10-31 00:18 -0500
Re: Obnoxious postings from Google Groups (was: datetime issue) alex23 <wuwei23@gmail.com> - 2012-09-16 17:47 -0700
Re: Obnoxious postings from Google Groups (was: datetime issue) Roy Smith <roy@panix.com> - 2012-09-16 20:55 -0400
Re: Obnoxious postings from Google Groups (was: datetime issue) alex23 <wuwei23@gmail.com> - 2012-09-16 18:14 -0700
Re: Obnoxious postings from Google Groups Robert Miles <robertmiles@teranews.com> - 2012-10-31 00:39 -0500
Re: Obnoxious postings from Google Groups Jamie Paul Griffin <jamie@kode5.net> - 2012-11-01 09:55 +0000
Re: Obnoxious postings from Google Groups rurpy@yahoo.com - 2012-11-01 15:08 -0700
Re: Obnoxious postings from Google Groups Chris Angelico <rosuav@gmail.com> - 2012-11-02 10:32 +1100
Re: Obnoxious postings from Google Groups Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-02 01:25 +0000
Re: Obnoxious postings from Google Groups Roy Smith <roy@panix.com> - 2012-11-01 21:42 -0400
Re: Obnoxious postings from Google Groups "Rhodri James" <rhodri@wildebst.demon.co.uk> - 2012-11-02 02:07 +0000
Re: Obnoxious postings from Google Groups Grant Edwards <invalid@invalid.invalid> - 2012-11-02 14:11 +0000
Re: Obnoxious postings from Google Groups Jamie Paul Griffin <jamie@kode5.net> - 2012-11-02 09:36 +0000
Re: Obnoxious postings from Google Groups rurpy@yahoo.com - 2012-11-02 11:39 -0700
Re: Obnoxious postings from Google Groups Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-11-03 00:06 +0000
Re: Obnoxious postings from Google Groups Jamie Paul Griffin <jamie@kode5.net> - 2012-11-04 11:13 +0000
Re: Obnoxious postings from Google Groups rusi <rustompmody@gmail.com> - 2012-11-04 22:10 -0800
Re: Obnoxious postings from Google Groups Chris Angelico <rosuav@gmail.com> - 2012-11-05 17:39 +1100
Re: Obnoxious postings from Google Groups rusi <rustompmody@gmail.com> - 2012-11-04 23:34 -0800
Re: Obnoxious postings from Google Groups Roy Smith <roy@panix.com> - 2012-11-05 07:56 -0500
Re: Obnoxious postings from Google Groups Chris Angelico <rosuav@gmail.com> - 2012-11-06 01:20 +1100
Re: Obnoxious postings from Google Groups Grant Edwards <invalid@invalid.invalid> - 2012-11-05 14:59 +0000
RE: Obnoxious postings from Google Groups "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-11-06 16:52 +0000
Re: Obnoxious postings from Google Groups Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-06 05:03 +0000
Re: Obnoxious postings from Google Groups Roy Smith <roy@panix.com> - 2012-11-06 08:52 -0500
Re: Obnoxious postings from Google Groups GangGreene <GangGreene@example.com> - 2012-11-06 11:51 -0500
Re: Obnoxious postings from Google Groups Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-06 23:14 +0000
Re: Obnoxious postings from Google Groups GangGreene <GangGreene@example.com> - 2012-11-06 19:16 -0500
Re: Obnoxious postings from Google Groups Grant Edwards <invalid@invalid.invalid> - 2012-11-07 15:13 +0000
Re: Obnoxious postings from Google Groups Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2012-11-07 18:52 +1300
Re: Obnoxious postings from Google Groups Roy Smith <roy@panix.com> - 2012-11-07 01:04 -0500
Re: Obnoxious postings from Google Groups Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-07 08:15 +0000
Re: Obnoxious postings from Google Groups Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-11-05 11:28 -0500
Re: Obnoxious postings from Google Groups Grant Edwards <invalid@invalid.invalid> - 2012-11-05 18:20 +0000
Re: Obnoxious postings from Google Groups Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-11-05 14:47 -0500
Re: Obnoxious postings from Google Groups Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-06 04:46 +0000
RE: Obnoxious postings from Google Groups "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-11-06 17:16 +0000
Re: Obnoxious postings from Google Groups Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-06 22:50 +0000
RE: Obnoxious postings from Google Groups "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-11-06 23:08 +0000
Re: Obnoxious postings from Google Groups Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-07 00:13 +0000
Re: Obnoxious postings from Google Groups Hans Mulder <hansmu@xs4all.nl> - 2012-11-09 12:34 +0100
Re: Obnoxious postings from Google Groups Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-10 06:57 +0000
RE: Obnoxious postings from Google Groups Kushal Kumaran <kushal.kumaran+python@gmail.com> - 2012-11-07 15:08 +0530
Re: Obnoxious postings from Google Groups Hans Mulder <hansmu@xs4all.nl> - 2012-11-09 10:49 +0100
Re: Obnoxious postings from Google Groups Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-09 11:30 +0000
Re: Obnoxious postings from Google Groups rurpy@yahoo.com - 2012-11-05 11:41 -0800
Re: Obnoxious postings from Google Groups Virgil Stokes <vs@it.uu.se> - 2012-11-04 17:52 +0100
Re: Obnoxious postings from Google Groups Bob Martin <bob.martin@excite.com> - 2012-11-03 07:44 +0000
Re: Obnoxious postings from Google Groups Dave Angel <d@davea.name> - 2012-11-03 10:24 -0400
Re: Obnoxious postings from Google Groups Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-03 16:18 +0000
Re: Obnoxious postings from Google Groups Chris Angelico <rosuav@gmail.com> - 2012-11-04 03:05 +1100
Re: Obnoxious postings from Google Groups Ian Kelly <ian.g.kelly@gmail.com> - 2012-11-02 11:42 -0600
Re: Obnoxious postings from Google Groups Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-11-04 18:39 +0000
Re: Obnoxious postings from Google Groups Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2012-11-09 12:02 +0100
Re: Obnoxious postings from Google Groups Robert Miles <robertmiles@teranews.com> - 2012-09-21 00:22 -0500
Re: Obnoxious postings from Google Groups (was: datetime issue) Grant Edwards <invalid@invalid.invalid> - 2012-09-21 15:07 +0000
Re: Obnoxious postings from Google Groups (was: datetime issue) Walter Hurry <walterhurry@lavabit.com> - 2012-09-21 22:11 +0000
Re: Obnoxious postings from Google Groups (was: datetime issue) Hank Gay <hank.gay+eternal.september@gmail.com> - 2012-09-21 20:51 -0400
Re: Obnoxious postings from Google Groups (was: datetime issue) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-09-22 00:13 -0400
Re: Obnoxious postings from Google Groups (was: datetime issue) Grant Edwards <invalid@invalid.invalid> - 2012-09-23 22:25 +0000
Re: Obnoxious postings from Google Groups Robert Miles <robertmiles@teranews.com> - 2012-10-31 00:07 -0500
Re: Obnoxious postings from Google Groups rurpy@yahoo.com - 2012-10-31 12:32 -0700
Re: Obnoxious postings from Google Groups Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-31 22:33 +0000
Re: Obnoxious postings from Google Groups Arnaud Delobelle <arnodel@gmail.com> - 2012-10-31 23:58 +0000
Re: Obnoxious postings from Google Groups Jamie Paul Griffin <jamie@kode5.net> - 2012-11-01 09:44 +0000
Re: datetime issue Roy Smith <roy@panix.com> - 2012-09-16 09:22 -0400
Re: datetime issue Chris Angelico <rosuav@gmail.com> - 2012-09-16 23:32 +1000
Re: datetime issue Chris Angelico <rosuav@gmail.com> - 2012-09-17 00:10 +1000
gc.get_objects() Matteo Boscolo <matteo.boscolo@boscolini.eu> - 2012-09-17 14:42 +0200
Re: gc.get_objects() Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-17 14:16 +0000
Re: gc.get_objects() Chris Angelico <rosuav@gmail.com> - 2012-09-18 02:09 +1000
Re: gc.get_objects() Matteo Boscolo <matteo.boscolo@boscolini.eu> - 2012-09-17 19:23 +0200
Re: gc.get_objects() Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2012-09-17 17:43 +0000
Re: datetime issue Grant Edwards <invalid@invalid.invalid> - 2012-10-31 15:11 +0000
Re: datetime issue rurpy@yahoo.com - 2012-10-31 12:35 -0700
Re: datetime issue Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-10-31 21:38 +0000
Re: datetime issue Robert Miles <robertmiles@teranews.com> - 2012-10-31 19:23 -0500
Re: datetime issue Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-11-01 00:36 +0000
Re: datetime issue rurpy@yahoo.com - 2012-11-01 15:00 -0700
Re: datetime issue Jamie Paul Griffin <jamie@kode5.net> - 2012-11-02 09:57 +0000
Re: datetime issue rurpy@yahoo.com - 2012-11-02 11:43 -0700
Re: datetime issue Robert Miles <robertmiles@teranews.com> - 2012-10-31 19:09 -0500
Re: datetime issue Grant Edwards <invalid@invalid.invalid> - 2012-11-01 12:09 +0000
Re: datetime issue rurpy@yahoo.com - 2012-11-01 15:28 -0700
Re: datetime issue "Günther Dietrich" <gd.usenet@spamfence.net> - 2012-09-16 15:22 +0200
Re: datetime issue pandora.koura@gmail.com - 2012-09-16 08:43 -0700
Re: datetime issue Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-09-16 15:35 -0400
Re: datetime issue MRAB <python@mrabarnett.plus.com> - 2012-09-16 16:27 +0100
Re: datetime issue pandora.koura@gmail.com - 2012-09-16 08:40 -0700
Re: datetime issue Chris Angelico <rosuav@gmail.com> - 2012-09-17 01:54 +1000
Re: datetime issue Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-09-16 20:23 +0100
Re: datetime issue pandora.koura@gmail.com - 2012-09-16 08:40 -0700
Re: datetime issue Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-09-16 15:37 -0400
Re: datetime issue Νικόλαος Κούρας <nikos.gr33k@gmail.com> - 2012-09-16 01:25 -0700
Re: datetime issue Νικόλαος Κούρας <nikos.gr33k@gmail.com> - 2012-09-15 22:15 -0700
Re: datetime issue Νικόλαος Κούρας <nikos.gr33k@gmail.com> - 2012-09-15 12:26 -0700
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-11-06 05:03 +0000 |
| Subject | Re: Obnoxious postings from Google Groups |
| Message-ID | <50989a16$0$29980$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #32750 |
On Mon, 05 Nov 2012 17:39:35 +1100, Chris Angelico wrote: > On Mon, Nov 5, 2012 at 5:10 PM, rusi <rustompmody@gmail.com> wrote: >> Among people who know me, I am a linux nerd: My sister scolded me >> yesterday because I put files on her computer without spaces: >> DoesAnyoneWriteLikeThis?!?! > > 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". -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2012-11-06 08:52 -0500 |
| Subject | Re: Obnoxious postings from Google Groups |
| Message-ID | <roy-2F6600.08523606112012@news.panix.com> |
| In reply to | #32802 |
In article <50989a16$0$29980$c3e8da3$5496439d@news.astraweb.com>,
Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> 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.
[toc] | [prev] | [next] | [standalone]
| From | GangGreene <GangGreene@example.com> |
|---|---|
| Date | 2012-11-06 11:51 -0500 |
| Subject | Re: Obnoxious postings from Google Groups |
| Message-ID | <nornm9-nhi.ln1@crazy-horse.bildanet.com> |
| In reply to | #32820 |
On Tue, 06 Nov 2012 08:52:36 -0500, Roy Smith wrote:
[putolin]
> 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.
Really?
I have just finished a 251 line bash shell script that builds my linux
distro from scratch. It uses other bash shell scripts that have more
lines per file/script and sources the individual package build bash
scripts. I used C for the package manager which is only non bash script
part of the entire package management system. The only thing I would
like to see in bash is to be able to return a string from a function.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-11-06 23:14 +0000 |
| Subject | Re: Obnoxious postings from Google Groups |
| Message-ID | <509999e0$0$29980$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #32833 |
On Tue, 06 Nov 2012 11:51:03 -0500, GangGreene wrote: > 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? :-P 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
[toc] | [prev] | [next] | [standalone]
| From | GangGreene <GangGreene@example.com> |
|---|---|
| Date | 2012-11-06 19:16 -0500 |
| Subject | Re: Obnoxious postings from Google Groups |
| Message-ID | <gslom9-s4j.ln1@crazy-horse.bildanet.com> |
| In reply to | #32850 |
On Tue, 06 Nov 2012 23:14:40 +0000, Steven D'Aprano wrote:
> On Tue, 06 Nov 2012 11:51:03 -0500, GangGreene wrote:
>
>> 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?
It has a host system for build/bootstraping. Then it goes onto an USB
drive, both as the OS and installation packages (with package manager)
capable of install on a system without an OS. Hard drive needed ;)
>
> 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.
I have used it for several years and others have used it to build their
own systems. I have used it on 586 to the latest multi core systems.
>
> 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.
I am not Redhat or Ubuntu (commercial distros stink) ;)
>
> 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?
It stops on all critical build errors and skips the package on minimal
errors, giving me a list of skipped packages and status on them at the
end of the build sequence (so I can fix my errors). It will also
download the source package if it is not present in the build directory.
If I incur any breakage/error ( it can happen a lot ) it stops and
notifies me. I then fix the package build script and lather/rinse/repeat
until I get the package build correct. It logs all the information into
build/testing/file listing/dependency requirements into log files. Then
the package goes off to a repository holding all the other packages. The
directory layout is like this:
build
+--section - programming/X window etc
+----package - python gcc coreutils and contains the
build script ( bash script ) and source package.
The build system ( bash scripts ) recurses this directory structure build
the packages and placing them into
repository
+-----base - base system packages kernel coreutils etc
+-----extra - programming packages, xorg etc here
The package manager (written in C) then looks to the repository to
install/update from the repository.
> Does it leave you with a broken system, half installed?
No. It builds all of the packages and then creates binary/devel packages
to be installed a new system. The finished packages go into a repository.
If I update a package only that package is built and placed into the
repository so all machine can be updated by my package manager. And yes
the build script automatically takes care of all build dependencies as
well as installed binary dependencies for the host installs. It will even
build itself.
>How easily can you maintain it after three months? Will it work in the
> presence of filenames with newlines in them?
I have maintained it for 8 years, and it can and does handle file names
with spaces, any valid *nix file name character can be used.
>
>
>
> [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.
Only from a certain points of view. I use many for loops and no if
statements. There is a good alternate for if, easily understandable if
you know C and boolean logic. My background is in C and Delphi/Pascal
and I didn't have problems with bash scripting. I want to have a go at
python.
Arch linux "pacman package management/build/delevopment system" is very
similar to mine. If you wish to take a look at it. It is also mostly
bash scripts with some C and python2/3 to boot.
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2012-11-07 15:13 +0000 |
| Subject | Re: Obnoxious postings from Google Groups |
| Message-ID | <k7dtrd$jru$1@reader1.panix.com> |
| In reply to | #32850 |
On 2012-11-06, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> On Tue, 06 Nov 2012 11:51:03 -0500, GangGreene wrote:
>
>> 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?
>
>:-P
>
> 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...
--
Grant Edwards grant.b.edwards Yow! I'm wet! I'm wild!
at
gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2012-11-07 18:52 +1300 |
| Subject | Re: Obnoxious postings from Google Groups |
| Message-ID | <afub8iFbvftU1@mid.individual.net> |
| In reply to | #32802 |
Steven D'Aprano wrote: > 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. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2012-11-07 01:04 -0500 |
| Subject | Re: Obnoxious postings from Google Groups |
| Message-ID | <roy-93FA2B.01044407112012@news.panix.com> |
| In reply to | #32872 |
In article <afub8iFbvftU1@mid.individual.net>, Gregory Ewing <greg.ewing@canterbury.ac.nz> wrote: > Steven D'Aprano wrote: > > 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. 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... >>> f = Foo() >>> setattr(f, "x y", "xyz") >>> dir(f) ['__doc__', '__module__', 'x y'] I did not expect this to work. Not quite sure what I've created here.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-11-07 08:15 +0000 |
| Subject | Re: Obnoxious postings from Google Groups |
| Message-ID | <509a188a$0$21759$c3e8da3$76491128@news.astraweb.com> |
| In reply to | #32872 |
On Wed, 07 Nov 2012 18:52:16 +1300, Gregory Ewing wrote: > Steven D'Aprano wrote: >> 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. 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 -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2012-11-05 11:28 -0500 |
| Subject | Re: Obnoxious postings from Google Groups |
| Message-ID | <mailman.3292.1352132880.27098.python-list@python.org> |
| In reply to | #32747 |
On Mon, 5 Nov 2012 17:39:35 +1100, Chris Angelico <rosuav@gmail.com>
declaimed the following in gmane.comp.python.general:
>
> 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}
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2012-11-05 18:20 +0000 |
| Subject | Re: Obnoxious postings from Google Groups |
| Message-ID | <k7901m$856$1@reader1.panix.com> |
| In reply to | #32776 |
On 2012-11-05, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
> On Mon, 5 Nov 2012 17:39:35 +1100, Chris Angelico <rosuav@gmail.com>
> declaimed the following in gmane.comp.python.general:
>
>>
>> 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>
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 '/'.
--
Grant Edwards grant.b.edwards Yow! I feel better about
at world problems now!
gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2012-11-05 14:47 -0500 |
| Subject | Re: Obnoxious postings from Google Groups |
| Message-ID | <mailman.3297.1352144862.27098.python-list@python.org> |
| In reply to | #32777 |
On Mon, 5 Nov 2012 18:20:38 +0000 (UTC), Grant Edwards
<invalid@invalid.invalid> declaimed the following in
gmane.comp.python.general:
> On 2012-11-05, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
> > On Mon, 5 Nov 2012 17:39:35 +1100, Chris Angelico <rosuav@gmail.com>
> > declaimed the following in gmane.comp.python.general:
> >
> >>
> >> 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>
>
> 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...
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-11-06 04:46 +0000 |
| Subject | Re: Obnoxious postings from Google Groups |
| Message-ID | <50989613$0$29980$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #32785 |
On Mon, 05 Nov 2012 14:47:47 -0500, Dennis Lee Bieber wrote:
>> 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...
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
[toc] | [prev] | [next] | [standalone]
| From | "Prasad, Ramit" <ramit.prasad@jpmorgan.com> |
|---|---|
| Date | 2012-11-06 17:16 +0000 |
| Subject | RE: Obnoxious postings from Google Groups |
| Message-ID | <mailman.3332.1352223438.27098.python-list@python.org> |
| In reply to | #32801 |
Steven D'Aprano wrote: > > 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 > line shells. 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 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.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-11-06 22:50 +0000 |
| Subject | Re: Obnoxious postings from Google Groups |
| Message-ID | <50999452$0$29980$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #32834 |
On Tue, 06 Nov 2012 17:16:44 +0000, Prasad, Ramit wrote: >> 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. 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. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | "Prasad, Ramit" <ramit.prasad@jpmorgan.com> |
|---|---|
| Date | 2012-11-06 23:08 +0000 |
| Subject | RE: Obnoxious postings from Google Groups |
| Message-ID | <mailman.3344.1352243319.27098.python-list@python.org> |
| In reply to | #32846 |
Steven D'Aprano wrote: > > On Tue, 06 Nov 2012 17:16:44 +0000, Prasad, Ramit wrote: > > >> 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. > > 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. > 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. :( ~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.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-11-07 00:13 +0000 |
| Subject | Re: Obnoxious postings from Google Groups |
| Message-ID | <5099a7ba$0$29980$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #32847 |
On Tue, 06 Nov 2012 23:08:11 +0000, Prasad, Ramit wrote: > Steven D'Aprano wrote: >> >> On Tue, 06 Nov 2012 17:16:44 +0000, Prasad, Ramit wrote: >> >> >> 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. >> >> 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. >> >> > 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.) -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Hans Mulder <hansmu@xs4all.nl> |
|---|---|
| Date | 2012-11-09 12:34 +0100 |
| Subject | Re: Obnoxious postings from Google Groups |
| Message-ID | <509cea43$0$6900$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #32856 |
On 7/11/12 01:13:47, Steven D'Aprano wrote: > On Tue, 06 Nov 2012 23:08:11 +0000, Prasad, Ramit wrote: > >> Steven D'Aprano wrote: >>> >>> On Tue, 06 Nov 2012 17:16:44 +0000, Prasad, Ramit wrote: >>> >>>>> 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. >>> >>> 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. >>> >>> >> 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".) 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
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-11-10 06:57 +0000 |
| Subject | Re: Obnoxious postings from Google Groups |
| Message-ID | <509dfabf$0$29980$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #33015 |
On Fri, 09 Nov 2012 12:34:27 +0100, Hans Mulder wrote: > On 7/11/12 01:13:47, Steven D'Aprano wrote: >> 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. 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". -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Kushal Kumaran <kushal.kumaran+python@gmail.com> |
|---|---|
| Date | 2012-11-07 15:08 +0530 |
| Subject | RE: Obnoxious postings from Google Groups |
| Message-ID | <mailman.3360.1352281096.27098.python-list@python.org> |
| In reply to | #32846 |
"Prasad, Ramit" <ramit.prasad@jpmorgan.com> writes: > Steven D'Aprano wrote: >> >> On Tue, 06 Nov 2012 17:16:44 +0000, Prasad, Ramit wrote: >> >> >> 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. >> >> 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. >> > > 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). -- regards, kushal
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.lang.python
csiph-web