Re: python 2.7.12 on Linux behaving differently than on Windows

On Sat, Dec 10, 2016 at 5:40 AM, Marko Rauhamaa wrote: >> How do you represent the current and previous directory in a list >> without reserving identifiers for them? > > My idea covered absolute pathnames only. Well, you're going to need to cope with relative pathnames

Re: python 2.7.12 on Linux behaving differently than on Windows

Steve D'Aprano : > On Fri, 9 Dec 2016 09:34 pm, Marko Rauhamaa wrote: >> Steve D'Aprano : >>> No that's incorrect. It isn't that . and .. are forbidden, but they >>> are reserved: every single directory in Unix file systems have a . >>> and

Re: python 2.7.12 on Linux behaving differently than on Windows

On Fri, 9 Dec 2016 09:34 pm, Marko Rauhamaa wrote: > Steve D'Aprano : > >> On Fri, 9 Dec 2016 04:52 pm, Marko Rauhamaa wrote: >>> In Linux, "." and ".." are taboo. >> >> No that's incorrect. It isn't that . and .. are forbidden, but they are >> reserved: every single

Re: python 2.7.12 on Linux behaving differently than on Windows

eryk sun : > Windows NTFS doesn't normalize names to a canonical form. It also > allows lone surrogate codes, which is invalid UTF-16. Somewhat related, surrogate codes are invalid Unicode and shouldn't be allowed in Unicode strings. However, Python does allow them. Marko --

Re: python 2.7.12 on Linux behaving differently than on Windows

On Fri, Dec 9, 2016 at 7:41 AM, Steve D'Aprano wrote: > Frankly, I think that Apple HFS+ is the only modern file system that gets > Unicode right. Not only does it restrict file systems to valid UTF-8 > sequences, but it forces them to a canonical form to avoid the é

Re: python 2.7.12 on Linux behaving differently than on Windows

On Fri, Dec 9, 2016 at 6:41 PM, Steve D'Aprano wrote: > On Fri, 9 Dec 2016 01:52 pm, Chris Angelico wrote: > >> On Fri, Dec 9, 2016 at 12:34 PM, BartC wrote: >>> With a case-sensitive file system, how do you search only for 'harry', >>> not knowing

Re: python 2.7.12 on Linux behaving differently than on Windows

Steve D'Aprano : > On Fri, 9 Dec 2016 04:52 pm, Marko Rauhamaa wrote: >> In Linux, "." and ".." are taboo. > > No that's incorrect. It isn't that . and .. are forbidden, but they are > reserved: every single directory in Unix file systems have a . and .. > directory

Re: python 2.7.12 on Linux behaving differently than on Windows

On Fri, 9 Dec 2016 04:52 pm, Marko Rauhamaa wrote: > Random832 : > >> On Thu, Dec 8, 2016, at 20:38, Dennis Lee Bieber wrote: >>> In the original 8.3 scheme -- no files "contained" a dot >> >> Yes, but they do now, and the compatibility quirks persist. > > When porting a

Re: python 2.7.12 on Linux behaving differently than on Windows

On Fri, 9 Dec 2016 01:52 pm, Chris Angelico wrote: > On Fri, Dec 9, 2016 at 12:34 PM, BartC wrote: >> With a case-sensitive file system, how do you search only for 'harry', >> not knowing what combinations of upper and lower case have been used? >> (It's a good thing Google

Re: python 2.7.12 on Linux behaving differently than on Windows

Random832 : > On Thu, Dec 8, 2016, at 20:38, Dennis Lee Bieber wrote: >> In the original 8.3 scheme -- no files "contained" a dot > > Yes, but they do now, and the compatibility quirks persist. When porting a Python program to Windows, I noticed the filename "aux" is

Re: python 2.7.12 on Linux behaving differently than on Windows

Chris Angelico : > On Fri, Dec 9, 2016 at 10:03 AM, Marko Rauhamaa wrote: >> I find it a bit annoying that "/" cannot be used in Linux filenames. >> Slashes have very common everyday uses and it's a pity they are >> reserved. Instead, ASCII control characters

Re: python 2.7.12 on Linux behaving differently than on Windows

On Thu, Dec 8, 2016, at 20:38, Dennis Lee Bieber wrote: > On Thu, 08 Dec 2016 10:37:27 -0500, Random832 > declaimed the following: > >There are other issues, like needing a way to do Windows' version of > >wildcard parsing with all its quirks, or at least some of its

Re: python 2.7.12 on Linux behaving differently than on Windows

On Fri, 9 Dec 2016 12:32 pm, Dennis Lee Bieber wrote: > There is always VMS: > > volume:[dir.sub.subsub]fn.ext;ver > > (where volume could be a hardware device or a logical name -- which is NOT > the same as an environment variable; only other place I've seen something > similar is the Amiga --

Re: python 2.7.12 on Linux behaving differently than on Windows

On Fri, Dec 9, 2016 at 12:34 PM, BartC wrote: > With a case-sensitive file system, how do you search only for 'harry', not > knowing what combinations of upper and lower case have been used? (It's a > good thing Google search isn't case sensitive!) This is handled by "case

Re: python 2.7.12 on Linux behaving differently than on Windows

With a case-sensitive file system, how do you search only for 'harry', not knowing what combinations of upper and lower case have been used? (It's a good thing Google search isn't case sensitive!) On Linux, I'd do "find . -iname harry". A lot, but not all, of the tools usually have options to

Re: python 2.7.12 on Linux behaving differently than on Windows

On 09/12/2016 00:55, Chris Angelico wrote: On Fri, Dec 9, 2016 at 10:19 AM, BartC wrote: So it it perfectly possible to have case conversion defined for English, while other alphabets can do what they like. And there we have it. Not only do you assume that English is

Re: python 2.7.12 on Linux behaving differently than on Windows

On Fri, Dec 9, 2016 at 10:19 AM, BartC wrote: > I get this (although I suspect Thunderbird will screw up the tabs); the code > I used follows at the end: Actually it came through just fine. Although, point of note: the case conversions of individual characters are not the same

Re: python 2.7.12 on Linux behaving differently than on Windows

On 12/08/2016 04:19 PM, BartC wrote: > What were we talking about again? Oh yes, belittling me because I work > with Windows! Yes it's kind of getting that way, which means this conversation is at an end. I don't think Chris or Steven or anyone else who has gone round and round with you has

Re: Linux terminals vs Windows consoles - was Re: python 2.7.12 on Linux behaving differently than on Windows

On 12/08/2016 02:46 PM, Gregory Ewing wrote: > Michael Torrie wrote: >> For example, on Macs, >> control-key is not normally used, but rather the Command-key (the apple >> key) which happens to be where the Alt key is on our PC keyboards. > > Actually, Alt is usually mapped to Option on a Mac.

Re: python 2.7.12 on Linux behaving differently than on Windows

On Fri, Dec 9, 2016 at 10:03 AM, Marko Rauhamaa wrote: > I find it a bit annoying that "/" cannot be used in Linux filenames. > Slashes have very common everyday uses and it's a pity they are > reserved. Instead, ASCII control characters are allowed, which is of no > use. How

Re: python 2.7.12 on Linux behaving differently than on Windows

On 08/12/2016 22:31, Chris Angelico wrote: On Fri, Dec 9, 2016 at 8:42 AM, BartC wrote: Python3 tells me that original, lower-case and upper-case versions are: ßẞıİiIÅσςσ ßßıi̇iiåσςσ SSẞIİIIÅΣΣΣ Now lower-case the upper-case version and see what you get. And upper-case the

Re: python 2.7.12 on Linux behaving differently than on Windows

Gregory Ewing : > Grant Edwards wrote: >> But _paths_ can, and Windows command-line apps and shells choke on >> paths when written with "/" separators because way-back when the >> MS-DOS "designers" decided to use "/" as the default option >> character. > > To be fair

Re: python 2.7.12 on Linux behaving differently than on Windows

On Fri, Dec 9, 2016 at 8:42 AM, BartC wrote: > Python3 tells me that original, lower-case and upper-case versions are: > > ßẞıİiIÅσςσ > ßßıi̇iiåσςσ > SSẞIİIIÅΣΣΣ Now lower-case the upper-case version and see what you get. And upper-case the lower-case version. Because

Re: Linux terminals vs Windows consoles - was Re: python 2.7.12 on Linux behaving differently than on Windows

Michael Torrie wrote: For example, on Macs, control-key is not normally used, but rather the Command-key (the apple key) which happens to be where the Alt key is on our PC keyboards. Actually, Alt is usually mapped to Option on a Mac. The Mac Command key corresponds the "Windows" or "Meta" key

Re: python 2.7.12 on Linux behaving differently than on Windows

On 08/12/2016 19:36, Chris Angelico wrote: On Fri, Dec 9, 2016 at 6:15 AM, BartC wrote: On 08/12/2016 03:41, Steven D'Aprano wrote: On Thursday 08 December 2016 12:15, BartC wrote: That's all. I know the value of keeping things straightforward instead of throwing in

Re: Linux terminals vs Windows consoles - was Re: python 2.7.12 on Linux behaving differently than on Windows

Michael Torrie wrote: Interesting. I wouldn't have thought ENTER would return a line feed. Possibly you have the terminal in "cbreak" mode, which provides a character at a time but still does things like translate CR->LF. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: python 2.7.12 on Linux behaving differently than on Windows

Grant Edwards wrote: But _paths_ can, and Windows command-line apps and shells choke on paths when written with "/" separators because way-back when the MS-DOS "designers" decided to use "/" as the default option character. To be fair to them, the use of "/" for options can be traced back to

Re: python 2.7.12 on Linux behaving differently than on Windows

On Fri, Dec 9, 2016 at 8:15 AM, Gregory Ewing wrote: > The main difference is that you're unlikely to accidentally > get a million file names or 131072 bytes of arguments that > way. :-) python3 argcount.py

Re: python 2.7.12 on Linux behaving differently than on Windows

Random832 wrote: Just to point out, brace expansion isn't globbing. The most important difference is that brace expansion doesn't care what files exist. However, it's something that the shell expands into multiple arguments, giving it similar characteristics for the purposes of this

Re: python 2.7.12 on Linux behaving differently than on Windows

On Fri, Dec 9, 2016 at 6:15 AM, BartC wrote: > On 08/12/2016 03:41, Steven D'Aprano wrote: >> >> On Thursday 08 December 2016 12:15, BartC wrote: >> > >>> That's all. I know the value of keeping things straightforward instead >>> of throwing in everything you can think of. The

Re: python 2.7.12 on Linux behaving differently than on Windows

On 08/12/2016 03:41, Steven D'Aprano wrote: On Thursday 08 December 2016 12:15, BartC wrote: That's all. I know the value of keeping things straightforward instead of throwing in everything you can think of. The file-matching is done by WinAPI functions. So you're happy with the fact that

Re: Linux terminals vs Windows consoles - was Re: python 2.7.12 on Linux behaving differently than on Windows

On 12/08/2016 10:05 AM, Grant Edwards wrote: > Or various other terminal emulators tha are mostly ANSI and Unicode > aware... > > And the Linux console... True. > > It's interesting to note that the "real" xterm terminal emulator will > still emulate a Tektronix storage-scope graphics terminal

Re: python 2.7.12 on Linux behaving differently than on Windows

On 2016-12-08, eryk sun wrote: > On Thu, Dec 8, 2016 at 4:34 PM, Grant Edwards > wrote: >> >> So, to avoid _that_ problem, Windows command line apps and the cmd.exe >> shell only allow "\" as a path separator. > > In cmd you can usually clarify the

Re: python 2.7.12 on Linux behaving differently than on Windows

On Thu, Dec 8, 2016 at 4:34 PM, Grant Edwards wrote: > > So, to avoid _that_ problem, Windows command line apps and the cmd.exe > shell only allow "\" as a path separator. In cmd you can usually clarify the intent with quotes, e.g. `dir C:/Windows` fails because it

Re: Linux terminals vs Windows consoles - was Re: python 2.7.12 on Linux behaving differently than on Windows

On 2016-12-08, Michael Torrie wrote: > Now we mostly just use one terminal type, "xterm." Or various other terminal emulators tha are mostly ANSI and Unicode aware... And the Linux console... It's interesting to note that the "real" xterm terminal emulator will still

Re: Linux terminals vs Windows consoles - was Re: python 2.7.12 on Linux behaving differently than on Windows

On 12/08/2016 09:35 AM, Michael Torrie wrote: > Yes Control codes are, well control codes. Any ascii value under 32. > They are more or less common across terminal types. I don't know of any > way around that with terminals. That is to say that on all terminal types that I'm aware of, the ENTER

Re: python 2.7.12 on Linux behaving differently than on Windows

On Thursday December 8 2016 11:48, in comp.lang.python, "Random832" wrote: > On Wed, Dec 7, 2016, at 15:29, Lew Pitcher wrote: >> But, point of fact is that the feature to disable globbing is not often >> needed. Most Unix programs that accept filenames are happy to

Re: python 2.7.12 on Linux behaving differently than on Windows

On Wed, Dec 7, 2016, at 22:41, Steven D'Aprano wrote: > Python's fnmatch lib is a good example. It has, or at least had, no > support for escaping metacharacters. Anyone relying on Python's fnmatch and > glob > modules alone for globbing will be unable to handle legitimate file names. That's not

Re: python 2.7.12 on Linux behaving differently than on Windows

On Wed, Dec 7, 2016, at 15:29, Lew Pitcher wrote: > But, point of fact is that the feature to disable globbing is not often > needed. Most Unix programs that accept filenames are happy to accept a > list of filenames. There is not much call for a program to perform it's own > globbing, like is

Linux terminals vs Windows consoles - was Re: python 2.7.12 on Linux behaving differently than on Windows

On 12/08/2016 05:43 AM, BartC wrote: > (Neither will see Shift+Ctrl+B, which means go to start of the file, > same as Ctrl+Home. Ubuntu sees Ctrl+Home, but not Debian, although it > will report Alt+Home. And some laptop keyboards already have Home on an > Alternate-Function shift! It's a mess.)

Re: python 2.7.12 on Linux behaving differently than on Windows

On 2016-12-08, Random832 wrote: > On Wed, Dec 7, 2016, at 03:50, Peter Otten wrote: >> Is there an equivalent to >> >> # touch -- -r >> >> on Windows? > > Doesn't need one - options conventionally start with /, and filenames > can't contain /. But _paths_ can, and

Re: python 2.7.12 on Linux behaving differently than on Windows

On Wed, Dec 7, 2016, at 03:50, Peter Otten wrote: > Is there an equivalent to > > # touch -- -r > > on Windows? Doesn't need one - options conventionally start with /, and filenames can't contain /. -- https://mail.python.org/mailman/listinfo/python-list

Re: python 2.7.12 on Linux behaving differently than on Windows

On Wed, Dec 7, 2016, at 00:15, Steven D'Aprano wrote: > and the shell expands the metacharacters ? {...} * [...] regardless of > how much > smarts the command itself has. > > There are thousands of programs I might use, and they may implement who > knows > how many different globbing rules: >

Re: python 2.7.12 on Linux behaving differently than on Windows

On Thu, Dec 8, 2016, at 01:20, Gregory Ewing wrote: > BartC wrote: > > And globbing doesn't take care of all of it: a Linux program still has > > to iterate over a loop of filenames. The same as on Windows, except the > > latter will need to call a function to deliver the next filename. > >

Re: python 2.7.12 on Linux behaving differently than on Windows

BartC wrote: Run the code below and start pressing keys. On both of my Linuxes, I get escape sequences shown when I Insert, Delete, Home, End, Page Up, Page Down, Up, Down, Left, Right and most of the function keys; not just single ASCII codes. That's probably because your terminal window is

Re: python 2.7.12 on Linux behaving differently than on Windows

On 08/12/2016 07:24, Gregory Ewing wrote: BartC wrote: (I'm in the middle of porting my console editor to Linux. But one problem is that on one Linux, half the key combinations (eg. Shift+Ctrl+B) are not recognised. If you're reading characters from a tty device in raw mode (which I assume

Re: python 2.7.12 on Linux behaving differently than on Windows

BartC wrote: Which means that input of A B* *C will all end up running together so that you have no idea what is what or which file corresponds to which expansion. So if you intend your program to be used on unix, you need to design it so that it doesn't depend on such distinctions. Now the

Re: python 2.7.12 on Linux behaving differently than on Windows

On 12/07/2016 11:26 PM, Gregory Ewing wrote: > BartC wrote: >> println dirlist(cmdparams[2])# Windows >> println tail(cmdparams) # Linux > > I'm not familiar with your language, so I'll reply > in Python. If you write it like this: > > for arg in sys.argv[1:]: >

Re: python 2.7.12 on Linux behaving differently than on Windows

BartC wrote: println dirlist(cmdparams[2])# Windows println tail(cmdparams) # Linux I'm not familiar with your language, so I'll reply in Python. If you write it like this: for arg in sys.argv[1:]: for name in glob(arg): print(name) then the user will

Re: python 2.7.12 on Linux behaving differently than on Windows

BartC wrote: Only the tiny minority that can be meaningfully invoked on an arbitrary number of files at the same time. Um... you mean the "tiny minority" that includes just about *every* unix utility that operates on files? -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: python 2.7.12 on Linux behaving differently than on Windows

BartC wrote: And globbing doesn't take care of all of it: a Linux program still has to iterate over a loop of filenames. The same as on Windows, except the latter will need to call a function to deliver the next filename. Actually, most of them will require *two* loops, one to iterate over a

Re: python 2.7.12 on Linux behaving differently than on Windows

Paul Moore wrote: On Tuesday, 6 December 2016 21:44:18 UTC, Gregory Ewing wrote: What you need to understand is that, to a Unix user, * and ? are *just as well known* as |, < and >. And to Windows users. Just because BartC is proposing a silly distinction between what "Unix users" and

Re: python 2.7.12 on Linux behaving differently than on Windows

Steve D'Aprano wrote: I don't know any Unix programs that provide file spec processing. 'find' does, but only for its -name argument, and only because it does something different with it from what the shell would do. And you do need to quote it if it contains glob characters. -- Greg --

Re: python 2.7.12 on Linux behaving differently than on Windows

On Thursday 08 December 2016 12:15, BartC wrote: > On 08/12/2016 00:09, Steve D'Aprano wrote: >> On Thu, 8 Dec 2016 02:48 am, BartC wrote: > >>> You make it sound like a big deal. Here's a program (in my language not >>> Python) which prints the list of files matching a file-spec: >>> >>>

Re: python 2.7.12 on Linux behaving differently than on Windows

On Thursday 08 December 2016 11:34, BartC wrote: > On 07/12/2016 23:35, Steve D'Aprano wrote: >> On Thu, 8 Dec 2016 02:19 am, BartC wrote: >> >>> On 07/12/2016 14:34, Steve D'Aprano wrote: >> [...] I don't know why you are so hung up over the number of characters here, or this bogeyman

Re: python 2.7.12 on Linux behaving differently than on Windows

On 08/12/2016 00:09, Steve D'Aprano wrote: On Thu, 8 Dec 2016 02:48 am, BartC wrote: You make it sound like a big deal. Here's a program (in my language not Python) which prints the list of files matching a file-spec: println dirlist(cmdparams[2]) Does dirlist provide an escaping mechanism

Re: python 2.7.12 on Linux behaving differently than on Windows

On Thu, Dec 8, 2016 at 10:35 AM, Steve D'Aprano wrote: > In the Unix world, I'm at the mercy of *one* program, the shell. In your > ideal world, I'm at the mercy of EVERY program that implements globbing: > each and every one has to independently offer a way to disable

Re: python 2.7.12 on Linux behaving differently than on Windows

On 07/12/2016 23:35, Steve D'Aprano wrote: On Thu, 8 Dec 2016 02:19 am, BartC wrote: On 07/12/2016 14:34, Steve D'Aprano wrote: [...] I don't know why you are so hung up over the number of characters here, or this bogeyman of "one million files" in a directory. Because /you/ brought it up

Re: python 2.7.12 on Linux behaving differently than on Windows

On Thu, 8 Dec 2016 07:01 am, Skip Montanaro wrote: > Some things are better just left alone. File globbing is probably one > of those things. There's no right answer, and the people in the two > camps will never come to a compromise. Be fair Skip, we've already repeatedly acknowledged that the

Re: python 2.7.12 on Linux behaving differently than on Windows

On Thu, 8 Dec 2016 02:48 am, BartC wrote: > On 07/12/2016 13:58, Dennis Lee Bieber wrote: >> On Wed, 7 Dec 2016 11:54:35 +, BartC declaimed the >> following: >> >>> With automatic expansion, then EVERY program can become dangerous. Can >>> no one else see this? >>> >> >>

Re: python 2.7.12 on Linux behaving differently than on Windows

On Thu, 8 Dec 2016 02:19 am, BartC wrote: > On 07/12/2016 14:34, Steve D'Aprano wrote: [...] >> I don't know why you are so hung up over the number of characters here, >> or this bogeyman of "one million files" in a directory. > > Because /you/ brought it up as a reason why 'globbing' would help

Re: python 2.7.12 on Linux behaving differently than on Windows

BartC writes: > On 07/12/2016 15:25, Ben Bacarisse wrote: >> BartC writes: >> >>> [...] But remember: >>> >>> cp *.c >>> >>> There might be some irate users out there if it can't detect a simple >>> user error like that. >> >> There might be. They are

Re: python 2.7.12 on Linux behaving differently than on Windows

On Thu, Dec 8, 2016 at 7:17 AM, eryk sun wrote: > On Wed, Dec 7, 2016 at 12:39 PM, Chris Angelico wrote: >> Note that two of the Beauty Stone tracks include quotes as well as >> question marks. How do you identify those? Let's say you want to play >> one of

Re: python 2.7.12 on Linux behaving differently than on Windows

Op 07-12-16 om 19:02 schreef BartC: > On 07/12/2016 16:53, Michael Torrie wrote: >> On 12/07/2016 08:48 AM, BartC wrote: >>> I would prefer that the program "t" can be invoked exactly the same way >>> under both systems. I don't want different instructions for Linux, or >>> for the user (of my

Re: python 2.7.12 on Linux behaving differently than on Windows

On Wednesday December 7 2016 14:57, in comp.lang.python, "BartC" wrote: > On 07/12/2016 18:02, BartC wrote: > >> If I want to run a Windows program on Linux, and that program needs to >> see *.* unexpanded, then it can't undo that expansion. The cat is >> already out of the

Re: python 2.7.12 on Linux behaving differently than on Windows

On Wed, Dec 7, 2016 at 12:39 PM, Chris Angelico wrote: > Note that two of the Beauty Stone tracks include quotes as well as > question marks. How do you identify those? Let's say you want to play > one of these in VLC, and then maybe you decide that the track in > Pirates of

Re: python 2.7.12 on Linux behaving differently than on Windows

On 07/12/2016 18:02, BartC wrote: If I want to run a Windows program on Linux, and that program needs to see *.* unexpanded, then it can't undo that expansion. The cat is already out of the bag. I mean, the genie is out of the bottle, whatever. You know what I mean, the operation is not

Re: python 2.7.12 on Linux behaving differently than on Windows

On Wed, Dec 7, 2016 at 12:17 PM, Anton Mamaenko wrote: > Wow... this thread gets to finally become a holy war. It's not like this particular holy war is new, either. I'm sure it was beaten to death in the days before Windows was a thing. As I indicated in an earlier note,

Re: python 2.7.12 on Linux behaving differently than on Windows

On 07/12/2016 15:25, Ben Bacarisse wrote: BartC writes: [...] But remember: cp *.c There might be some irate users out there if it can't detect a simple user error like that. There might be. They are ill-served by current Unix shells. But, oddly, the flow has gone the

Re: python 2.7.12 on Linux behaving differently than on Windows

Wow... this thread gets to finally become a holy war. One method is dealing with this is take the environment as granted (Windows/Unix/Linux/MacOS/Dos sucks while my Windows/Unix/Linux/MacOS/Dos is the best) and figure if the hassle of porting (time, tech, AND moral) worth it. He just "do not

Re: python 2.7.12 on Linux behaving differently than on Windows

On 07/12/2016 16:53, Michael Torrie wrote: On 12/07/2016 08:48 AM, BartC wrote: I would prefer that the program "t" can be invoked exactly the same way under both systems. I don't want different instructions for Linux, or for the user (of my language) to have to write two lots of code, as that

Re: python 2.7.12 on Linux behaving differently than on Windows

On 12/07/2016 07:57 AM, BartC wrote: > I don't follow you. "?" is problematical on both systems. I think > Windows disallows it completely: I get 'Protocol error' if I copy such a > file from Linux to Windows. Presumably there is an escaping system, but > I don't know what it is. As Chris

Re: python 2.7.12 on Linux behaving differently than on Windows

On 12/07/2016 08:48 AM, BartC wrote: > I would prefer that the program "t" can be invoked exactly the same way > under both systems. I don't want different instructions for Linux, or > for the user (of my language) to have to write two lots of code, as that > is my job... Ahh now we come to

Re: python 2.7.12 on Linux behaving differently than on Windows

On 12/07/2016 07:58 AM, Marko Rauhamaa wrote: > Steve D'Aprano : > >> I don't know any Unix programs that provide file spec processing. >> (That's not to say that there are absolutely none, only that I don't >> know of any.) > > I can think of "find", "git" and "scp".

Re: python 2.7.12 on Linux behaving differently than on Windows

On Thu, Dec 8, 2016 at 2:19 AM, BartC wrote: > OK, but you go first: how does a Linux program tell the difference between: > > A B C > > which signifies three files, and: > > A B C > > which means two files, and an option C? And without using escapes! The option would be

Re: python 2.7.12 on Linux behaving differently than on Windows

On Thu, Dec 8, 2016 at 1:57 AM, BartC wrote: > On 07/12/2016 12:39, Chris Angelico wrote: >> >> On Wed, Dec 7, 2016 at 10:54 PM, BartC wrote: >>> >>> But if a program existed that took N filename parameters with the purpose >>> of >>> deleting each of them, then

Re: python 2.7.12 on Linux behaving differently than on Windows

On 07/12/2016 13:58, Dennis Lee Bieber wrote: On Wed, 7 Dec 2016 11:54:35 +, BartC declaimed the following: With automatic expansion, then EVERY program can become dangerous. Can no one else see this? With your scheme, EVERY PROGRAM HAS TO IMPLEMENT ITS OWN

Re: python 2.7.12 on Linux behaving differently than on Windows

BartC writes: > [...] But remember: > > cp *.c > > There might be some irate users out there if it can't detect a simple > user error like that. There might be. They are ill-served by current Unix shells. But, oddly, the flow has gone the other way. People have wanted Unix

Re: python 2.7.12 on Linux behaving differently than on Windows

On 07/12/2016 14:34, Steve D'Aprano wrote: On Wed, 7 Dec 2016 11:23 pm, BartC wrote: On 07/12/2016 05:15, Steven D'Aprano wrote: On Wednesday 07 December 2016 12:55, BartC wrote: But even Linux's 128KB will fill if someone wanted a command line that listed 20,000 files individually. But it

Re: python 2.7.12 on Linux behaving differently than on Windows

On Wednesday, 7 December 2016 11:55:01 UTC, BartC wrote: > With automatic expansion, then EVERY program can become dangerous. Can > no one else see this? Please start an elevated command prompt on your PC, and type the command rmdir /s /q C:\WINDOWS There are no special characters here,

Re: python 2.7.12 on Linux behaving differently than on Windows

On Tuesday, 6 December 2016 21:44:18 UTC, Gregory Ewing wrote: > BartC wrote: > > But those would be silly. > > > > Some special syntax is known about: | < and > for example. % less so > > What you need to understand is that, to a Unix user, > * and ? are *just as well known* as |, < and >.

Re: python 2.7.12 on Linux behaving differently than on Windows

Steve D'Aprano : > I don't know any Unix programs that provide file spec processing. > (That's not to say that there are absolutely none, only that I don't > know of any.) I can think of "find", "git" and "scp". Git supports the recursive "**" wildcard, as well.

Re: python 2.7.12 on Linux behaving differently than on Windows

On 07/12/2016 12:39, Chris Angelico wrote: On Wed, Dec 7, 2016 at 10:54 PM, BartC wrote: But if a program existed that took N filename parameters with the purpose of deleting each of them, then it can't tell if they were typed in individually (so indicating a stronger intent),

Re: python 2.7.12 on Linux behaving differently than on Windows

On Tuesday, 6 December 2016 16:34:10 UTC, Michael Torrie wrote: > On 12/06/2016 06:52 AM, BartC wrote: > > Then you don't get utterly ridiculous and dangerous behaviour such as > > the cp example Paul Moore came up with (that trumps most of mine actually): > > It's potentially dangerous agreed.

Re: python 2.7.12 on Linux behaving differently than on Windows

On Wed, 7 Dec 2016 11:23 pm, BartC wrote: > On 07/12/2016 05:15, Steven D'Aprano wrote: >> On Wednesday 07 December 2016 12:55, BartC wrote: >> >>> But even Linux's 128KB will fill if someone wanted a command line that >>> listed 20,000 files individually. But it would be spectacularly bad use

Re: python 2.7.12 on Linux behaving differently than on Windows

On Wed, Dec 7, 2016 at 9:43 AM, Chris Angelico wrote: > Exactly. Back in the 1990s, we had the beginnings of Windows NT, which > was designed for servers. It had (if I recall correctly) no concept of > file/directory permissions, little or no notion of process privilege, > and

Re: python 2.7.12 on Linux behaving differently than on Windows

On Thu, 8 Dec 2016 12:07 am, eryk sun wrote: >> latest step is Microsoft's partnership with Canonical (the company behind >> Ubuntu Linux) to bring bash to Windows. > > The partnership with Canonical is to provide an entire Linux > distribution, sans the kernel. The Windows Subsystem for Linux

Re: python 2.7.12 on Linux behaving differently than on Windows

Chris Angelico : > $ find Music/ -name *\\?* I do recommend quoting your wildcard characters. Yet further nasty security pitfalls in bash programming: 5. Wildcards that don't match any file are left unexpanded. 6. Commands behave unexpectedly when given null lists: $

Re: python 2.7.12 on Linux behaving differently than on Windows

On Wed, Dec 7, 2016 at 8:30 AM, Steven D'Aprano wrote: > > There are Windows programs which understand globs, like dir. Do you honestly > expect us to believe that it is okay to use "dir a*" on Windows because dir > itself expands the glob, but not okay to

Re: python 2.7.12 on Linux behaving differently than on Windows

On Wed, Dec 7, 2016 at 10:54 PM, BartC wrote: > But if a program existed that took N filename parameters with the purpose of > deleting each of them, then it can't tell if they were typed in individually > (so indicating a stronger intent), or whether a finger slipped on a single

Re: python 2.7.12 on Linux behaving differently than on Windows

On 07/12/2016 05:15, Steven D'Aprano wrote: On Wednesday 07 December 2016 12:55, BartC wrote: But even Linux's 128KB will fill if someone wanted a command line that listed 20,000 files individually. But it would be spectacularly bad use of a command line interface which was designed for

Re: python 2.7.12 on Linux behaving differently than on Windows

On 07/12/2016 08:30, Steven D'Aprano wrote: On Wednesday 07 December 2016 03:41, BartC wrote: On 06/12/2016 15:44, Michael Torrie wrote: On 12/06/2016 04:43 AM, BartC wrote: Yes shell expansion has it's gotchas. But those can all be learned, Yes, learn to avoid wildcards in command

Re: python 2.7.12 on Linux behaving differently than on Windows

On Wed, Dec 7, 2016 at 7:30 PM, Steven D'Aprano wrote: > If you accidentally say "del *" on Windows, say, when you meant "z*" for > example, and Windows deletes all the files in the current directory, do you > say > to yourself...? > >"Thank the deities

Re: python 2.7.12 on Linux behaving differently than on Windows

Steven D'Aprano wrote: > Tell me Bart, what's the difference between these? > > # Linux > rm * > > and > > # Windows > del * Is there an equivalent to # touch -- -r on Windows? Like in $ tree . |-- -r |-- a | `-- b | `-- c | `-- bar.txt `-- foo.txt 3 directories, 3

Re: python 2.7.12 on Linux behaving differently than on Windows

On Wednesday 07 December 2016 03:41, BartC wrote: > On 06/12/2016 15:44, Michael Torrie wrote: >> On 12/06/2016 04:43 AM, BartC wrote: > >> Yes shell expansion has it's gotchas. But those can all be learned, > > Yes, learn to avoid wildcards in command parameters at all costs. But we > both

Re: python 2.7.12 on Linux behaving differently than on Windows

On Wednesday 07 December 2016 10:37, BartC wrote: > On 06/12/2016 21:44, Gregory Ewing wrote: >> BartC wrote: > >>> And the justification? Well, %ENVIRONMENTVARIABLE% gets converted in >>> Windows, so why not?! >> >> No, the justification is that the Unix convention allows >> the shell to

Re: python 2.7.12 on Linux behaving differently than on Windows

On Wednesday 07 December 2016 12:55, BartC wrote: > But even Linux's 128KB will fill if someone wanted a command line that > listed 20,000 files individually. But it would be spectacularly bad use > of a command line interface which was designed for humans. That's EXACTLY the point of having the

Re: python 2.7.12 on Linux behaving differently than on Windows

On Tue, Dec 6, 2016 at 10:35 PM, Nathan Ernst wrote: > One other consideration in regards to globbing in the argument list: > there's a static limit to the byte length of argv. On windows, it's 8191 > bytes (I'm assuming a null-terminator brings that to 8192, which is a

Re: python 2.7.12 on Linux behaving differently than on Windows

On Wed, Dec 7, 2016 at 1:30 AM, Dennis Lee Bieber wrote: > (Bah... win10 seems to share parts of the PowerShell console config with > the old command prompt -- making it nearly impossible [at least in the > three days I've been on Win10 after the Win7 drive failed] to

Re: python 2.7.12 on Linux behaving differently than on Windows

On 12/06/2016 03:21 AM, BartC wrote: On 06/12/2016 07:37, Larry Hudson wrote: Now you're suggesting the _shell_ is going to read and process a CVS file??? What follows a shell command is a set of values a,b,c,d,e. What is encountered in a CSV is a set of values a,b,c,d,e. You really can't

  1   2   3   >