Re: python 2.7.12 on Linux behaving differently than on Windows
On Monday, 5 December 2016 18:21:57 UTC, Chris Angelico wrote: > On Tue, Dec 6, 2016 at 5:02 AM, BartC wrote: > > > > how do you tell whether the last file in an argument list is the optional > > 'file', or the last file of the expansion of 'filespec'? > > Why should you care? I have used shell globbing to pass precisely two > parameters to a program. More often, I use this syntax, which Windows > simply doesn't support: You might care. I occasionally teach Unix to beginners, and a common gotcha is the fact that cp a/* . copies everything from a to the current directory. But if you miss typing the ".", the behaviour is *very* different. And the cp command has no way to know or warn you that you might have mistyped. The find command is another, more "advanced" example. find . -name foo* works as "expected" as long as there's no file that matches the glob in the current directory (because in that case the shell passes the pattern through unchanged). But users who get used to this behaviour get a nasty surprise when they hit a case where it doesn't apply and they *need* to quote. It's a trade-off. Unix makes shells do globbing, so programs don't have to, but as a consequence they have no means of seeing whether globbing occurred, or switching it off for particular argument positions. Windows chooses to make the trade-off a different way. Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Monday, 5 December 2016 17:14:27 UTC, Skip Montanaro wrote: > ISTR that the way DOS/Windows operate at the text prompt level was > modeled on VMS. As you indicated, each command was responsible for its > own "globbing". I've never programmed in DOS or Windows, and its been > decades since I programmed in VMS, but I imagine that both > environments probably provide some standard sort of globbing library. Technically, the primitive "launch an executable" operation in Windows takes a *command line* to pass to the new process, rather than a list of arguments. The argv convention comes to Windows via C, which is derived from Unix. So the C runtime historically provided argv splitting to match C semantics, and added globbing as a convenience "because people were used to it from Unix" (even though in Unix it was a shell feature, not a C/application feature). There's also an OS API to do cmdline->argv conversion, for programs that don't want to rely on the C runtime capability. The result is the same, though - in Windows, applications (or the language runtime) handle globbing, but in Unix the shell does. Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
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 see the similarity? Suppose instead of: command a b c d e The interface was changed to be more interactive: command Input: a b c d e So parameters are not entered on the command line, but are prompted for. Do you think entering a b c d e here should give exactly the same results as doing so on the command line? As far as any user is concerned, they should. But they can't because in the in-line example, parameters could be expanded. And there seems to be no way of turning that off, without changing the input (eg. quotes around parameters). Shell command line processing shouldn't be attempting anything more than that. I get awfully tired of your constant pontificating about your opinions. Opinions based on facts: I've given a dozen examples where the shell's auto-expansion can screw things up. And I can easily come up with more, as have others in the thread. People's attitudes seem to be 'So don't that'. Or, 'So what?'. Which suggests there is an actual problem that is being brushed under the carpet. I know they're _VERY_ strongly held beliefs on your part, but... they are ONE person's opinions and are no more than opinions and they ain't gonna change nothin', no how, no way, not ever. No they're not. But the auto-expansion of parameters by default is still wrong. [Sorry, I'm in a bad mood today and just had to let off a little steam...] People spout off about Windows ALL the time. 'So what?' -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Tue, Dec 6, 2016 at 10:21 PM, BartC wrote: > 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 see the > similarity? > > Suppose instead of: > > command a b c d e > > The interface was changed to be more interactive: > > command > Input: a b c d e > > So parameters are not entered on the command line, but are prompted for. Do > you think entering a b c d e here should give exactly the same results as > doing so on the command line? > > As far as any user is concerned, they should. Here are two Python statements: x = 1, 2, 3, 4, 5 f(x) f(1, 2, 3, 4, 5) As far as any user is concerned, these should do the exact same thing. After all, they both have five numbers separated by commas. There's absolutely no reason for them to do anything different. And it should be exactly the same if you write it like this: f(input()) and type "1, 2, 3, 4, 5" at the prompt. Right? Why do you continue to claim that shells should do no parsing, yet expect parsing to happen elsewhere? Why are shells somehow different? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 06/12/2016 02:21, Dennis Lee Bieber wrote: On Mon, 5 Dec 2016 18:50:30 +, BartC declaimed the following: It doesn't matter, and is not the concern of the shell. It should restrict itself to the basic parsing that may be necessary when Another name for "shell" is "command line interpreter" -- emphasis on "interpreter"... They are languages in their own right, with their own rules. I distinguish between proper languages and those that just process commands like those you type in to applications that use command line input: > kill dwarf with axe You don't really expect input like: >HOW ARE YOU? VERY WELL THANKS! [An actual demo of a board computer in the 1970s] to be transformed into: HOW ARE YOUA YOUB YOUC The Windows command prompt being one of the weakest -- it doesn't support arithmetic and local variables, nor (to my knowledge) looping constructs. It does some of that, but very crudely. If you want scripting, then use a scripting language. There are plenty about. A typical Windows user who uses the command prompt will have no idea they are doing coding. And they're not. /I/ don't expect that on Unix either. One would be very annoyed if, reading a CSV file, where each of N values on a line correspond to a field of record, if one entry of "?LBC" expanded itself to a dozen entries, screwing everything up. Meaningless argument... You are, here, /reading a data file/, not interpreting the contents as command lines. They're both data. Read the Python documentation for argparse I just tried it, but it was too complex for me to set it up so as to discover with it did with * arguments. Again, start with argparse... Any command line argument that is left after it has parsed the line can likely be considered a "filename". Only at the end? And to handle the difference between Windows and UNIX you'd likely need something like: for aParm in remainingArguments: for aFile in glob.glob(aParm): do something with the file Suppose any argument contains * or ?, isn't a filename, but happens to match some files in the current directory. AFAICS it will still screw up. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 06/12/2016 07:08, Gregory Ewing wrote: BartC wrote: And if there's an error in an option, you may have to abort, which means throwing away that list of files which, in some cases, can run into millions. This "millions of files" thing seems to be an imaginary monster you've invented to try to scare people. I claim that, to a very good approximation, it doesn't exist. I've never encountered a directory containing a million files, and if such a thing existed, it would be pathological in enough other ways to make it a really bad idea. Many of my examples are based on actual experience. One of my machines /did/ have 3.4 million files in one directory. (The result of Firefox file caching having run amok for the best part of a year. Once discovered, it took 15 hours to delete them all.) In that directory (which was on Windows but accessible via a virtual Linux), typing any Linux command followed by * would have required all 3.4 million directory entries to be accessed in order to build a 3.4 million-element argv list. I've no idea how long that would have taken. >DIR *.b *.c Not with *that particular syntax*. You would need to design the interface of a program to do that some other way. EXACTLY. It's restrictive. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Detect Linux Runlevel
On 2016-12-05 23:00, Wildman via Python-list wrote:
> On Mon, 05 Dec 2016 21:42:52 -0600, Tim Chase wrote:
> > This works based on my poking at it in both Py2 and Py3:
>
> That works perfectly. I owe you a big thanks. That was a
> lot of work and time on your part. I really appreciate it.
It was pretty straightforward to map it into a namedtuple using the
links I provided. The only killer for me was that the struct module
doesn't return an entry for "padding" bytes. Which makes sense, but
threw me off for a good while as I tried to figure why my
tuple-creation was complaining about a missing parameter (fixed by
commenting out the "__unused" member of the namedtuple; could also
have kept it while changing the "20x" to "20c" in the struct
format-string)
The rest was just basic text manipulation in vim to convert the C
structs into Python code.
And despite what Bernd Nawothnig wrote:
> It looks for me like a worthless learning experience.
it gave me the opportunity to learn about the internals of the utmp
format, something that has long been a curiosity ("it's a binary log,
not text, I wonder what all is in there? But I don't have real cause
to go poking around in there to learn the answer right now.") and this
gave me the push I needed to explore that.
Glad it helped.
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Tue, Dec 6, 2016 at 10:56 PM, BartC wrote: > In that directory (which was on Windows but accessible via a virtual Linux), > typing any Linux command followed by * would have required all 3.4 million > directory entries to be accessed in order to build a 3.4 million-element > argv list. I've no idea how long that would have taken. I just asked Python to build me a 4-million-element list, and it took no visible time - a small fraction of a second. Don't be afraid of large argument lists. We're not writing 8088 Assembly Language programs in 64KB of working memory here. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Tue, Dec 6, 2016 at 2:51 AM, Nathan Ernst wrote: > On Mon, Dec 5, 2016 at 8:44 PM, Steve D'Aprano > wrote: >> On Tue, 6 Dec 2016 10:09 am, eryk sun wrote: >> >> > The default Windows shell is "cmd.exe", and it's informally called the >> > "Command Prompt", >> >> Thanks for the correction, I always mix up cmd/command . exe/com. I fear >> this won't be the last time either -- I wish there was a good mnemonic for >> which is which. There are a few executables that end in .com: chcp.com, format.com, mode.com, more.com, and tree.com. These are 32-bit / 64-bit PE/COFF binaries, the same as any other Windows executable. > Ify ou're running on Windows 10, at least, you can soon purge that memory. > command.com doesn't exist (may never have existed on Win2k, XP, Vista, 7, > 8, 8.1 or 10). If I try and run either "command" or "command.com" from > Win10, both say command cannot be found. Only 32-bit versions of Windows include the NT Virtual DOS Machine (ntvdm.exe) for running 16-bit DOS programs. Such programs expect a 8086 real-mode execution environment, in which the DOS kernel hooks interrupt 0x21 for its system-call interface. To provide this environment, NTVDM uses a virtual 8086 mode monitor that's built into the 32-bit kernel. x86-64 long mode doesn't allow switching the CPU to v86 mode, so NTVDM isn't available in 64-bit Windows. In this case the kernel's entry point for VDM control is hard coded to return STATUS_NOT_IMPLEMENTED (0xC002), as the following disassembly shows: lkd> u nt!NtVdmControl nt!NtVdmControl: f801`4710 b802c0 mov eax,0C002h f801`4715 c3 ret > IIRC, command.com was a relic of Win9x running on top of DOS and was a > 16-bit executable, so inherently crippled (and probably never support by > the NT kernel). COMMAND.COM is a 16-bit DOS program, which was the "DOS prompt" in Windows 3.x and 9x. The versions of Windows that ran on DOS had a complicated design (in 386 Enhanced Mode) that used a virtual 8086 monitor that ran in 32-bit protected mode. As far back as Windows 3.1, Microsoft started replacing some DOS system services with functionality implemented in 32-bit VxDs. Some among us may recall the big performance improvement that 32-bit disk access provided in Windows for Workgroups 3.11. In Windows 9x most DOS system calls were implemented in 32-bit protected mode VxDs; they even reflected calls in v86 mode up to the 32-bit implementation. Thus much of the implementation underlying the Win32 API used 32-bit code in protected mode. That said, initially in Windows 95 there were still a lot of Win32 API calls that ended up executing real-mode 16-bit DOS calls in the system VM. The book "Unauthorized Windows 95" analyzes this in detail. > Whereby cmd.exe coexisted but ran in a 32-bit context. cmd.exe (command prompt) is a Windows application -- for the most part, though it does go beyond the Windows API to peek at the NT process environment block (PEB) of child processes. It was ported to but never distributed with Windows 9x. On Windows 9x you instead had an actual DOS prompt that ran COMMAND.COM in virtual 8086 mode. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
BartC wrote: I've given a dozen examples where the shell's auto-expansion can screw things up. Only because you're taking Windows conventions and trying to apply them to Unix. That's like somebody from the USA visiting Britain and thinking "OMG! These people are all going to get themselves killed, they're driving on the wrong side of the road!" -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Tue, Dec 6, 2016 at 12:26 PM, Chris Angelico wrote: > On Tue, Dec 6, 2016 at 10:56 PM, BartC wrote: >> In that directory (which was on Windows but accessible via a virtual Linux), >> typing any Linux command followed by * would have required all 3.4 million >> directory entries to be accessed in order to build a 3.4 million-element >> argv list. I've no idea how long that would have taken. > > I just asked Python to build me a 4-million-element list, and it took > no visible time - a small fraction of a second. Don't be afraid of > large argument lists. We're not writing 8088 Assembly Language > programs in 64KB of working memory here. The problem isn't building an arbitrary list with millions of elements. The problem is the time it would take to read millions of filenames from a directory. It depends on the performance of the disk and filesystem. Be careful with globbing. Think about the consequences before running a command, especially if you're in the habit of creating directories with hundreds of thousands, or millions, of files. It's not a problem that I've ever had to deal with. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 2016-12-06, Chris Angelico wrote:
> On Tue, Dec 6, 2016 at 10:56 PM, BartC wrote:
>> In that directory (which was on Windows but accessible via a virtual Linux),
>> typing any Linux command followed by * would have required all 3.4 million
>> directory entries to be accessed in order to build a 3.4 million-element
>> argv list. I've no idea how long that would have taken.
>
> I just asked Python to build me a 4-million-element list, and it took
> no visible time - a small fraction of a second. Don't be afraid of
> large argument lists. We're not writing 8088 Assembly Language
> programs in 64KB of working memory here.
To be fair, literally just now I couldn't run the command I wanted to:
sed -i -e 's/foo/bar/g' /dir/ectory/*.txt
because there were 300,000 files matching the glob, and 'sed' can't
cope with that many command-line arguments. I had to do this instead:
find /dir/ectory -name '*.txt' -exec sed -i -e 's/foo/bar/g' {} \;
(Yes, I could also have done something with 'xargs' instead, which
would've been slower to write and quicker to run.)
However please don't take that to mean I agree with BartC - he's
clearly just reacting with instinctive hostility to the unknown.
--
https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 06/12/2016 12:40, Gregory Ewing wrote: BartC wrote: I've given a dozen examples where the shell's auto-expansion can screw things up. Only because you're taking Windows conventions and trying to apply them to Unix. What, the convention of NOT assuming that any command parameter that uses * or ? MUST refer to whatever set of filenames happen to match in the current directory? And to then insert N arbitrary filenames in the parameter list. That's a pretty good convention, yes?! (Or should that be yesx! yesy!) That's like somebody from the USA visiting Britain and thinking "OMG! These people are all going to get themselves killed, they're driving on the wrong side of the road!" Or someone from Britain visiting the USA and saying OMG, everyone's got a gun! Suppose someone runs amok and shoots everybody! -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 06/12/2016 12:26, Chris Angelico wrote: On Tue, Dec 6, 2016 at 10:56 PM, BartC wrote: In that directory (which was on Windows but accessible via a virtual Linux), typing any Linux command followed by * would have required all 3.4 million directory entries to be accessed in order to build a 3.4 million-element argv list. I've no idea how long that would have taken. I just asked Python to build me a 4-million-element list, and it took no visible time - a small fraction of a second. Don't be afraid of large argument lists. We're not writing 8088 Assembly Language programs in 64KB of working memory here. Haven't people been saying that Unix has been doing this for 40 years? Some systems /did/ have little memory, and while there won't have been the capacity for that many files, some file devices were slow. -- Bartc -- 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 12:25 AM, BartC wrote: > What, the convention of NOT assuming that any command parameter that uses * > or ? MUST refer to whatever set of filenames happen to match in the current > directory? And to then insert N arbitrary filenames in the parameter list. > > That's a pretty good convention, yes?! Right! And while you're at it, stop assuming that percent signs have meaning, that quotes have meaning, etc, etc, etc. Right? And why should the enter key be significant - what if you want to send more than one line of command line arguments? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 06/12/2016 13:34, Chris Angelico wrote: On Wed, Dec 7, 2016 at 12:25 AM, BartC wrote: What, the convention of NOT assuming that any command parameter that uses * or ? MUST refer to whatever set of filenames happen to match in the current directory? And to then insert N arbitrary filenames in the parameter list. That's a pretty good convention, yes?! Right! And while you're at it, stop assuming that percent signs have meaning, that quotes have meaning, etc, etc, etc. Right? And why should the enter key be significant - what if you want to send more than one line of command line arguments? But those would be silly. Some special syntax is known about: | < and > for example. % less so (I've never, ever used it in live input AFAIK). This auto-expansion causes so many problems, places so many restrictions on what can be done, that it doesn't make sense. Auto-expanding parameters is such a big deal, that it should not be the default behaviour; it needs something to tell the command processor to expand. 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): Start with a directory containing two files c.c and d.c. You want to copy all .c files elsewhere, but accidentally type this: > cp *.c which ends up doing: > cp c.c d.c cp (or a program wanting to do anything like this) expects two arguments to be entered. But with auto-expansion, that is impossible to determine. And the justification? Well, %ENVIRONMENTVARIABLE% gets converted in Windows, so why not?! -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Detect Linux Runlevel
On 2016-12-06 01:14, Bernd Nawothnig wrote: > > I am a hobby programmer and I've been trying to learn python > > for a few months now. The program is 'worthlessware' but it > > is a 'learning experience' for me. > > It looks for me like a worthless learning experience. Eh, one person's "worthless learning experience" is another person's curiosity-satisfying education. I found it an exercise in learning something new about the utmp log format (previously an opaque binary blob) > > A friend wrote a similar program in Bash script and I have been > > working on translating it to Python. > > Stay with shell script for such tasks. It is never a good idea to > choose the programming language before closer evaluating the > problem. Based on the OP's description, this is a small part of a much larger program. And I would personally rather maintain a large Python code-base than a large Bash code-base. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Django broken pipe error
Hi,
I'm facing strange Django broken pipe error (Python 2.7 on Ubuntu) that
apparently is a not fixed Django bug. Does anybody now how to fix it? I've been
searching a lot and didn't find any solution.
This error happens very irregularly by Post request in Django. Sometimes it
works sometimes not:
[06/Dec/2016 13:33:57] "POST /export_report/ HTTP/1.1" 500 59
Traceback (most recent call last):
File "/usr/lib/python2.7/SocketServer.py", line 593, in process_request_thread
self.finish_request(request, client_address)
File "/usr/lib/python2.7/SocketServer.py", line 334, in finish_request
self.RequestHandlerClass(request, client_address, self)
File
"/home/ait/.virtualenvs/env1/local/lib/python2.7/site-packages/django/core/servers/basehttp.py",
line 129, in __init__
super(WSGIRequestHandler, self).__init__(*args, **kwargs)
File "/usr/lib/python2.7/SocketServer.py", line 651, in __init__
self.finish()
File "/usr/lib/python2.7/SocketServer.py", line 710, in finish
self.wfile.close()
File "/usr/lib/python2.7/socket.py", line 279, in close
self.flush()
File "/usr/lib/python2.7/socket.py", line 303, in flush
self._sock.sendall(view[write_offset:write_offset+buffer_size])
error: [Errno 32] Broken pipe
Exception happened during processing of request from ('127.0.0.1', 38224)
It is also described in:
https://www.reddit.com/r/joinmarket/comments/4atqrm/is_this_exception_normal_exception_happened/
On https://bugs.python.org/issue14574 is stated that this error should already
be fixed but apparently not.
Best regards,
Roman
--
https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Tuesday, 6 December 2016 13:25:40 UTC, BartC wrote: > On 06/12/2016 12:40, Gregory Ewing wrote: > > BartC wrote: > >> I've given a dozen examples where the shell's auto-expansion can screw > >> things up. > > > > Only because you're taking Windows conventions and trying > > to apply them to Unix. > > What, the convention of NOT assuming that any command parameter that > uses * or ? MUST refer to whatever set of filenames happen to match in > the current directory? And to then insert N arbitrary filenames in the > parameter list. Correct - with the exception that it's not that it MUST - there's ways to prevent that happening, just ones that aren't the default. > That's a pretty good convention, yes?! Yes. It has its benefits. > (Or should that be yesx! yesy!) No, because the rules for text in an email are different from those for text in a shell. But you seem to be arguing that the rules should be the same everywhere, so maybe in your world, yes it should be. Most other people understand the concept of context, though. Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Mon, Dec 5, 2016, at 21:21, Dennis Lee Bieber wrote: > They are languages in their own right, with their own rules. > > The Windows command prompt being one of the weakest -- it doesn't > support arithmetic and local variables, nor (to my knowledge) looping > constructs. BAT files are limited to something like 9 parameters (which > may > be the only argument for not expanding wildcards at the command line > level). There are only nine that you can name explicitly, but there's no obstacle to handling more with shift or %*. Also, there is a 'for' loop, though the syntax is somewhat arcane (and you can always loop with if/goto) It can do arithmetic with 'set /a', and there is a 'setlocal' command for local variable scopes. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Tue, Dec 6, 2016, at 02:01, Larry Hudson via Python-list wrote: > On 12/05/2016 06:51 PM, Nathan Ernst wrote: > > IIRC, command.com was a relic of Win9x running on top of DOS and was a > > 16-bit executable, so inherently crippled (and probably never support by > > the NT kernel). Whereby cmd.exe coexisted but ran in a 32-bit context. > > I know my 79-year-old memory is definitely subject to "senior moments" > and not too reliable, but > IIRC it was Windows prior to 9x (Win 3 and earlier) that were 16 bit and > ran on top of DOS. > Win95 was the first 32 bit version and was independent from DOS. Yes but there was no* 32-bit windows command interpreter - it ran DOS in a virtual machine inside it. Windows 3 did the same, actually - the real architecture of Windows/386 was a 32-bit protected mode host kernel called VMM32.VXD that ran all of Windows in one virtual machine and each DOS window in another one, leading to the odd consequence of there being cooperative multitasking between Windows apps but pre-emptive multitasking between DOS apps [and between them and Windows]. The fact that Windows was launched at boot by running "win.com" (either in autoexec.bat or manually at the command line) created a *perception* that windows ran "on top of DOS", but running it really *replaced* DOS in memory, putting the CPU into protected mode and everything. The ability to boot into (or exit to) DOS was because people still did real work (and games) in DOS and the virtual environment of DOS-on-Windows didn't perform well enough to be sufficient. *Well, I vaguely remember a version of cmd.exe that would run on Windows 98 floating around back in the day, but it certainly didn't come with the OS. It might have been a pirated Windows NT component. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 12/06/2016 04:43 AM, BartC wrote: >> Read the Python documentation for argparse > > I just tried it, but it was too complex for me to set it up so as to > discover with it did with * arguments. > >> Again, start with argparse... Any command line argument that is left >> after it has parsed the line can likely be considered a "filename". > > Only at the end? No, that's not what he said. After arguments have been parsed out and dealt with, whatever is left can be retrieved as the parameters (whether those are filenames or urls or something. All remaining parameters. Wherever they appeared. Some argument parsers do require all arguments to be first on the command line. argparse is not one of them. BSD tools typically do want args first. And actually a lot of windows applications are extremely picky about where the arguments come vs the "filespec" parameters. > And to >> handle the difference between Windows and UNIX you'd likely need something >> like: >> >> for aParm in remainingArguments: >> for aFile in glob.glob(aParm): >> do something with the file > > Suppose any argument contains * or ?, isn't a filename, but happens to > match some files in the current directory. AFAICS it will still screw up. Precisely! And you can bet there is probably more than one Windows program out there that incorrectly makes this assumption and does the wrong thing. Or the opposite is true and there are programs that expect no globs and can do nothing with them. And for such a buggy program there's not a darn thing the user can do to escape the glob or otherwise tell the program it's not a glob. That's why I would far rather place globbing in control of the shell where a user can properly deal with it, escape it, or otherwise disable it when necessary. Yes shell expansion has it's gotchas. But those can all be learned, whereas it's much harder to learn and remember all the gotchas and bugs of many individual applications' unique ways of dealing with globs. I'd rather deal with shells. -- https://mail.python.org/mailman/listinfo/python-list
Re: Detect Linux Runlevel
On Tue, 06 Dec 2016 01:14:35 +0100, Bernd Nawothnig wrote: > On 2016-12-05, Wildman wrote: >> And I am trying to write it without using external programs, where >> possible. > > That is not the Unix way. Yes, but it is my way. >> I am a hobby programmer and I've been trying to learn python >> for a few months now. The program is 'worthlessware' but it >> is a 'learning experience' for me. > > It looks for me like a worthless learning experience. It is sad that you consider learning something new to be worthless. I used the term "worthlessware" in an economical sense, meaning it has little or no commercial value. However, from a learning standpoint I consider it to be priceless. >> A friend wrote a similar program in Bash script and I have been >> working on translating it to Python. > > Stay with shell script for such tasks. It is never a good idea to > choose the programming language before closer evaluating the problem. You have a right to your opinion but I fail to see what that has to do with the price of eggs. I picked Python just because I wanted to learn it not because I had a particular problem to solve. If your job was to advocate Python, I would suggest you find another line of work. -- GNU/Linux user #557453 The cow died so I don't need your bull! -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 12/06/2016 06:52 AM, BartC wrote: > But those would be silly. But why? > Some special syntax is known about: | < and > for example. % less so > (I've never, ever used it in live input AFAIK). Yup and why would you think the ? * special syntax is not known about or should be known about? Very strange that you would treat them so differently. By the way I use %% environment variable expansion all the time in Windows. In fact I most use it in file open dialog boxes or in the Run dialog. If I want to see my home folder in a hurry, I'll type Win-R and then put "%userprofile%" in the box and hit enter. Very convenient. For me it's faster to then to browse through explorer and pick folders. Also it should work regardless of locale, and even if folder names are localized. > This auto-expansion causes so many problems, places so many restrictions > on what can be done, that it doesn't make sense. Auto-expanding > parameters is such a big deal, that it should not be the default > behaviour; it needs something to tell the command processor to expand. Yet you seem to be unable to see that applications doing their own expansion can also cause problems and restrictions and even worse, there's not a darn thing you as a user can do about it. > > 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. So are lots of commands like rm -rf / (which some shells will ask you about). If you understand a few basic rules of expansion, you can understand easily what happened or would happen. I'm not sure but I think many distros by default in the shell profiles alias cp="cp -i" and rm="rm -i" to help newbies. I know the root account has those aliases by default. I'm pretty sure I've disabled those aliases for my personal user account because they get in the way of a lot of my common operations. Again, I point out that these behaviors can be changed and altered by the user if he so desires. Right at the shell level. Instead of having to alter applications themselves that aren't too smart about things. -- https://mail.python.org/mailman/listinfo/python-list
Re: Detect Linux Runlevel
On 12/06/2016 06:51 AM, Tim Chase wrote: > Based on the OP's description, this is a small part of a much larger > program. And I would personally rather maintain a large Python > code-base than a large Bash code-base. Absolutely. Especially when you consider inxi is 12,000 lines of bash code in one file. Shudder. Though I'm sure bash made it very easy to interact with dozens or even hundreds of different external programs on dozens of operating systems and distributions to gather information. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
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 know that is not satisfactory. And it's not much help when someone types in: program * and the program has to try and clean up the mess, if it can see it is a mess. But remember: cp *.c There might be some irate users out there if it can't detect a simple user error like that. whereas it's much harder to learn and remember all the gotchas and bugs of many individual applications' unique ways of dealing with globs. I'd rather deal with shells. OK, I understand. Having a program launcher indiscriminately transform input A into A' is /much/ better than having it done by the program, even if the program doesn't want it and it is not meaningful. The fact that you also lose format information (is it three parameters, or one parameter transformed into three) is an extra bonus. This is clearly much better than any other scheme because: (1) It's Unix not Windows; everything in Unix is always better and always make sense. (2) There have been 40 years of it working this way and there have never been any problems. (That is, 40 years of writing programs with stultified command line interfaces to make sure that is always the case. [As for 'problems' such as the 'cp *.c' one, that's a feature!] -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Detect Linux Runlevel
On 12/06/2016 09:18 AM, Wildman via Python-list wrote: > It is sad that you consider learning something new to > be worthless. I used the term "worthlessware" in an > economical sense, meaning it has little or no commercial > value. However, from a learning standpoint I consider > it to be priceless. Well said. Some of us get hung up so much on the proper way to do something that we end up not doing much at all, other than talk about the proper way to do things. I tend to have this problem. While I talked about the proper and theoretical ways of doing agricultural GPS coverage mapping, another person with less formal programming training than I started hacking and you know what? He has a functioning program now that actually works. It's in C# (which I don't love), and it's got rough spots in the code and it's a bit difficult to add certain features to, but he simply went and did and learned as he went. Now he's at the point where he could refactor (and do it quickly) to get the architecture a bit more robust. But the point is I wasted all my time thinking about how I might do it and he just did it. Was very instructive to me. >>> A friend wrote a similar program in Bash script and I have been >>> working on translating it to Python. >> >> Stay with shell script for such tasks. It is never a good idea to >> choose the programming language before closer evaluating the problem. > > You have a right to your opinion but I fail to see what > that has to do with the price of eggs. I picked Python > just because I wanted to learn it not because I had a > particular problem to solve. If your job was to advocate > Python, I would suggest you find another line of work. I appreciate your measured response to what could be seen as an inflammatory post. Sometimes I think it all depends on the purpose for which you do something. In this case it's for fun, so knock yourself out. If you were instead writing this as part of a requirement for some enterprise server process professionally, you'd probably want to stick with Bash rather than shoe-horn Python into a systems programming language and shell-scripting language, which it's not really that good at. I can say this given my professional experience with server shell scripting. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 2016-12-06 13:08, eryk sun wrote: On Tue, Dec 6, 2016 at 12:26 PM, Chris Angelico wrote: On Tue, Dec 6, 2016 at 10:56 PM, BartC wrote: In that directory (which was on Windows but accessible via a virtual Linux), typing any Linux command followed by * would have required all 3.4 million directory entries to be accessed in order to build a 3.4 million-element argv list. I've no idea how long that would have taken. I just asked Python to build me a 4-million-element list, and it took no visible time - a small fraction of a second. Don't be afraid of large argument lists. We're not writing 8088 Assembly Language programs in 64KB of working memory here. The problem isn't building an arbitrary list with millions of elements. The problem is the time it would take to read millions of filenames from a directory. It depends on the performance of the disk and filesystem. Be careful with globbing. Think about the consequences before running a command, especially if you're in the habit of creating directories with hundreds of thousands, or millions, of files. It's not a problem that I've ever had to deal with. Many years ago I was working with a database application running on MSDOS that stored predefined queries in files, one query per file. There were many queries (though fewer than a thousand), resulting in many small files in a single directory. Fetching one of those predefined queries was surprisingly slow. I found that it was a lot faster to put them into a single file and then call an external program to extract the one wanted. It also took up a lot less disk space! -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 2016-12-06 13:52, BartC wrote: On 06/12/2016 13:34, Chris Angelico wrote: On Wed, Dec 7, 2016 at 12:25 AM, BartC wrote: What, the convention of NOT assuming that any command parameter that uses * or ? MUST refer to whatever set of filenames happen to match in the current directory? And to then insert N arbitrary filenames in the parameter list. That's a pretty good convention, yes?! Right! And while you're at it, stop assuming that percent signs have meaning, that quotes have meaning, etc, etc, etc. Right? And why should the enter key be significant - what if you want to send more than one line of command line arguments? But those would be silly. Some special syntax is known about: | < and > for example. % less so (I've never, ever used it in live input AFAIK). [snip] You've never used ImageMagick? If you want to shrink an image to half its size: convert dragon.gif -resize 50% half_dragon.gif -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 06/12/2016 17:00, MRAB wrote: On 2016-12-06 13:52, BartC wrote: Some special syntax is known about: | < and > for example. % less so (I've never, ever used it in live input AFAIK). [snip] You've never used ImageMagick? If you want to shrink an image to half its size: convert dragon.gif -resize 50% half_dragon.gif No. But that '50%' is seen by apps (eg. with Python's 'print sys.argv') on both Windows and Linux. However, I can imagine that a calculator app might have trouble with some expressions: calculate 3*5 This expression might be seen as 345 if there happens to be file called '345' lying around. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Tuesday December 6 2016 12:36, in comp.lang.python, "BartC" wrote: > On 06/12/2016 17:00, MRAB wrote: >> On 2016-12-06 13:52, BartC wrote: > >>> Some special syntax is known about: | < and > for example. % less so >>> (I've never, ever used it in live input AFAIK). >>> >> [snip] >> >> You've never used ImageMagick? >> >> If you want to shrink an image to half its size: >> >> convert dragon.gif -resize 50% half_dragon.gif > > No. But that '50%' is seen by apps (eg. with Python's 'print sys.argv') > on both Windows and Linux. > > However, I can imagine that a calculator app might have trouble with > some expressions: > > calculate 3*5 I can't see this being an issue with the "calculator app", unless the calculator app itself is written to perform file globbing. It /might/ be an issue with the shell, if you permit it to glob the "calculator app" arguments before invoking the "calculator app" binary. But, then again, Unix shell filename globbing is something that the user can disable temporarily or permanently if necessary. For example: calculate '3*5' or sh -o noglob -c "calculate 3*5" or even sh -o noglob calculate 3*5 > This expression might be seen as 345 if there happens to be file called > '345' lying around. Only if shell globbing is enabled, and you don't specifically bypass it. -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request -- https://mail.python.org/mailman/listinfo/python-list
Re: Detect Linux Runlevel
On Mon, 05 Dec 2016 16:08:57 -0600, Tim Chase wrote:
> On 2016-12-05 14:58, Wildman via Python-list wrote:
>> I there a way to detect what the Linux runlevel is from
>> within a Python program? I would like to be able to do
>> it without the use of an external program such as 'who'
>> or 'runlevel'.
>
> You can use something like
>
> https://gist.github.com/likexian/f9da722585036d372dca
I went back to the code from the above link to try to
get it to work with Python3, just to see if I could.
The problem was that the output was in bytes or partly
in bytes like this:
['1', '53', "b'~\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\
x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\ (...)
I was trying to convert the bytes to strings and that
is what I never got to work right. It didn't occur
to me that all I needed was the first two fields and
they were already strings.
The 'print output' part of the original code was this
which printed everything. Over kill for my use:
data = read_xtmp('/var/run/utmp')
for i in data:
print i
I changed it to this and it works:
data = read_xtmp('/var/run/utmp')
for i in data:
if i[0] == "1":
print("Runlevel: " + chr(int(i[1]) & 0xFF))
break
The output: Runlevel: 5
If I had tried this in the beginning, it would have
save you a lot of work.
Since both versions of the code works, which one do
you recommend? Or does it matter?
--
GNU/Linux user #557453
The cow died so I don't need your bull!
--
https://mail.python.org/mailman/listinfo/python-list
Re: When will they fix Python _dbm?
On Mon, Dec 5, 2016 at 5:06 PM, clvanwall wrote: > will thid do? John > Looks like you need to use dbm.ndbm.open() instead of just dbm.open(). See the docs here for more info: https://docs.python.org/3/library/dbm.html#module-dbm.ndbm -- https://mail.python.org/mailman/listinfo/python-list
Re: Django broken pipe error
On Tue, Dec 6, 2016 at 6:21 AM, wrote:
> Hi,
>
> I'm facing strange Django broken pipe error (Python 2.7 on Ubuntu) that
> apparently is a not fixed Django bug. Does anybody now how to fix it? I've
> been searching a lot and didn't find any solution.
>
> This error happens very irregularly by Post request in Django. Sometimes
> it works sometimes not:
>
> [06/Dec/2016 13:33:57] "POST /export_report/ HTTP/1.1" 500 59
> Traceback (most recent call last):
> File "/usr/lib/python2.7/SocketServer.py", line 593, in
> process_request_thread
> self.finish_request(request, client_address)
> File "/usr/lib/python2.7/SocketServer.py", line 334, in finish_request
> self.RequestHandlerClass(request, client_address, self)
> File "/home/ait/.virtualenvs/env1/local/lib/python2.7/site-
> packages/django/core/servers/basehttp.py", line 129, in __init__
> super(WSGIRequestHandler, self).__init__(*args, **kwargs)
> File "/usr/lib/python2.7/SocketServer.py", line 651, in __init__
> self.finish()
> File "/usr/lib/python2.7/SocketServer.py", line 710, in finish
> self.wfile.close()
> File "/usr/lib/python2.7/socket.py", line 279, in close
> self.flush()
> File "/usr/lib/python2.7/socket.py", line 303, in flush
> self._sock.sendall(view[write_offset:write_offset+buffer_size])
> error: [Errno 32] Broken pipe
>
> Exception happened during processing of request from ('127.0.0.1', 38224)
>
> It is also described in: https://www.reddit.com/r/
> joinmarket/comments/4atqrm/is_this_exception_normal_exception_happened/
>
> On https://bugs.python.org/issue14574 is stated that this error should
> already be fixed but apparently not.
>
> Best regards,
>
> Roman
Hi Roman,
Is this happening on the dev server or a production server? Did you use the
command ./manage.py runserver to start the server?
Can you please provide the code for the view class/function that is
throwing the error? I believe that this issue
may be caused by a call to the database not being structured correctly.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Detect Linux Runlevel
On 2016-12-06 12:10, Wildman via Python-list wrote: > If I had tried this in the beginning, it would have > save you a lot of work. > > Since both versions of the code works, which one do > you recommend? Or does it matter? Heh, I'm not sure it matters much. The code I provided should be expandable for tidily handling other entries in utmp, allowing you to search for other system events that might interest you (check out the invocation of the filter() function which filters by type). Since I've already done the leg-work, I mildly advocate using my version since it should be pretty clean and easy to expand. But if you want the satisfaction of using your code, I won't take offense :-) -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Detect Linux Runlevel
On Tue, 06 Dec 2016 13:06:35 -0600, Tim Chase wrote: > On 2016-12-06 12:10, Wildman via Python-list wrote: >> If I had tried this in the beginning, it would have >> save you a lot of work. >> >> Since both versions of the code works, which one do >> you recommend? Or does it matter? > > Heh, I'm not sure it matters much. The code I provided should be > expandable for tidily handling other entries in utmp, allowing you to > search for other system events that might interest you (check out the > invocation of the filter() function which filters by type). Yes, your code is very expandable and I will keep it archived for that reason. In the future I might want to delve further into utmp. But right now all I need is the runlevel. > Since I've already done the leg-work, I mildly advocate using my > version since it should be pretty clean and easy to expand. But if > you want the satisfaction of using your code, I won't take offense :-) > > -tkc Yes, I think I will use my code. No offense intended. :-) Again, I do appreciate all your work on my behalf. I hope some day I can return the favor. -- GNU/Linux user #557453 The cow died so I don't need your bull! -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
BartC wrote: What, the convention of NOT assuming that any command parameter that uses * or ? MUST refer to whatever set of filenames happen to match in the current directory? Yes. That's a pretty good convention, yes?! That's a matter of opinion. It precludes the shell from performing various services that Unix users like their shells to provide. Or someone from Britain visiting the USA and saying OMG, everyone's got a gun! Suppose someone runs amok and shoots everybody! If you expect us to trust most Americans not to misuse their guns, you will appreciate us asking you to trust most Unix users not to misuse their wildcard patterns. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: When will they fix Python _dbm?
On Mon, Dec 5, 2016 at 7:45 AM, clvanwall wrote: > I have been a Perl programmer for 15+ years and decided to give Python a try. > My platform is windows and I installed the latest 3.5.2. Next I decided to > convert a perl program that uses a ndbm database since according to the doc > on python, it should be able to work with it. Needless to say, I get: > dbm.error: db type is dbm.ndbm, but the module is not available > Searching on Python Bug Tracker shows _dbm missing back in 03-03-2012! > That's a long time for a bug to be left open. Are you referring to http://bugs.python.org/issue14185? That's on Linux platforms and it has to do with building Python, not using it. The dbm.ndbm documentation specifically says that it provides an interface to the *Unix* ndbm library: https://docs.python.org/3/library/dbm.html#module-dbm.ndbm. I don't think that this module is part of the standard Windows distribution of Python. You might be able to find a third-party distribution of the module using a Windows port of ndbm, or you could try to build it yourself. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
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 >. Perhaps even more so, because they're likely to be used much sooner than piping and redirection. And when learning about them, the fact that they're interpreted by the shell is learned at the same time. And the justification? Well, %ENVIRONMENTVARIABLE% gets converted in Windows, so why not?! No, the justification is that the Unix convention allows the shell to provide certain useful functions that Unix users value. If you don't want those functions, you're free to write your own shell that works however you want. Complaining that everyone *else* should want the same things you want is not reasonable. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 06Dec2016 16: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 know that is not satisfactory. Sigh. I'm sure this has all been thrashed out in this huge thread, but: that is what quoting is for (in the shell): to control whether wildcards are expanded or not. You, the typist, get to decide. And it's not much help when someone types in: program * and the program has to try and clean up the mess, if it can see it is a mess. Some invocations will be nonsense, and a program may catch those. But if that was actually the typist's intent, and the program says "nah!"? But remember: cp *.c There might be some irate users out there if it can't detect a simple user error like that. If there are _2_ .c files present, that will indeed misbehave. But often there are several, and cp detects the "copy several things to one target" mode for: cp a.c b.c d.c target-dir and says the final target (eg "d.c") is not a directory. A degree of safety. This is the circumstance where the request, as it is received, is nonsense and detectably so. Not perfectly robust, but you can never be perfectly robust against the typist making a mistaken request, globbing or not. whereas it's much harder to learn and remember all the gotchas and bugs of many individual applications' unique ways of dealing with globs. I'd rather deal with shells. OK, I understand. Having a program launcher indiscriminately transform input A into A' is /much/ better than having it done by the program, even if the program doesn't want it and it is not meaningful. It isn't indiscriminate; quoting lets the typist discriminate. Michael's point is that at least you're always using the _same_ command line conventions about what shall be expanded and what shall not, rather than a rule per app. The fact that you also lose format information (is it three parameters, or one parameter transformed into three) is an extra bonus. Feh. If *.c matches 3 files and I didn't quote, it is 3 parameters in my mind. If I wanted one parameter I'd have said '*.c' (<== quotes). This is clearly much better than any other scheme because: (1) It's Unix not Windows; everything in Unix is always better and always make sense. UNIX rules are often simpler and more consistent. (2) There have been 40 years of it working this way and there have never been any problems. (That is, 40 years of writing programs with stultified command line interfaces to make sure that is always the case. [As for 'problems' such as the 'cp *.c' one, that's a feature!] Nothing prevents you writing an extremely simple shell yourself you know. It needn't expand anything. _Or_ you could have it adopt the inverse convention: expand nothing unless asked. Eg: cp G:*.c to cause "*.c" to get expanded. Of course, because the various executables don't feel any burden to implement globbing you may run into some impedence mismatch. Cheers, Cameron Simpson -- 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 8:46 AM, Cameron Simpson wrote: > Nothing prevents you writing an extremely simple shell yourself you know. It > needn't expand anything. _Or_ you could have it adopt the inverse > convention: expand nothing unless asked. Eg: > > cp G:*.c > > to cause "*.c" to get expanded. Of course, because the various executables > don't feel any burden to implement globbing you may run into some impedence > mismatch. I actually have something like this in one application's inbuilt command executor - it does globbing ONLY if the parameter starts with a question mark (eg "?*.c" will glob "*.c" in that directory). It's deliberate, but frankly, it ends up annoying more often than not. I'm considering switching to a more normal way of doing it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Detect Linux Runlevel
Tim Chase : > This works based on my poking at it in both Py2 and Py3: Great info, Tim. A word a warning: your code doesn't lock /var/run/utmp before access, which is a race condition. The file may be updated at any time, and ordinary file reads may yield corrupted records. The library functions getutline(), pututline() etc lock the file internally (although that is not documented). You can see the (advisory record) locking in action by running the command strace who Since the locking scheme hasn't been documented, the only safe way to read /var/run/utmp is through the C API functions. Another thing is that, as stated before, the runlevel business is legacy. It is still supported by systemd-update-utmp, but for how long is anybody's guess. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
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 weird 2**13). For Linux, as of kernal 2.6.25, apparently, the limit is 131072 bytes, an equally odd choice of 2**17 bytes. I'm not sure if globs directly to commands bypass these restrictions, but I've seen real world issues with build systems with thousands of files that attempted to pass all dependencies to a target that blew up spectacularly (one of the reasons cl & link on windows accept argument files as input instead of just command line arguments). Regards, Nate On Tue, Dec 6, 2016 at 4:24 PM, Chris Angelico wrote: > On Wed, Dec 7, 2016 at 8:46 AM, Cameron Simpson wrote: > > Nothing prevents you writing an extremely simple shell yourself you > know. It > > needn't expand anything. _Or_ you could have it adopt the inverse > > convention: expand nothing unless asked. Eg: > > > > cp G:*.c > > > > to cause "*.c" to get expanded. Of course, because the various > executables > > don't feel any burden to implement globbing you may run into some > impedence > > mismatch. > > I actually have something like this in one application's inbuilt > command executor - it does globbing ONLY if the parameter starts with > a question mark (eg "?*.c" will glob "*.c" in that directory). It's > deliberate, but frankly, it ends up annoying more often than not. I'm > considering switching to a more normal way of doing it. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > -- 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 9:35 AM, 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 weird 2**13). For > Linux, as of kernal 2.6.25, apparently, the limit is 131072 bytes, an > equally odd choice of 2**17 bytes. > > I'm not sure if globs directly to commands bypass these restrictions, but > I've seen real world issues with build systems with thousands of files that > attempted to pass all dependencies to a target that blew up spectacularly > (one of the reasons cl & link on windows accept argument files as input > instead of just command line arguments). A lot of things are a problem in an ecosystem they're not designed for, but work fine if you have them. If the normal thing is to have the shell expand globs, the system will expect and assume this, applications will expect and assume this, and the shell will do this. If the normal thing is not to, then nobody will expect it. This is only going to be a problem when you mix ecosystems; for instance, I don't know what the Win 10 internal bash does, with a limit like that, and I don't know how Wine apps cope with file names that include metacharacters in them. But when everything's built consistently, you don't have a problem. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 12/06/2016 03: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 weird > 2**13). For Linux, as of kernal 2.6.25, apparently, the limit is 131072 > bytes, an equally odd choice of 2**17 bytes. > > I'm not sure if globs directly to commands bypass these restrictions, but > I've seen real world issues with build systems with thousands of files that > attempted to pass all dependencies to a target that blew up spectacularly > (one of the reasons cl & link on windows accept argument files as input > instead of just command line arguments). Applications that can do their own globbing do avoid this command-line length limit for sure, at least in these situations. Instead of excepting one or more filenames on the command-line, it could accept a filespec, a single field. So one million files would just be "foo *.*". This is part of what Bart really likes about the windows way of doing things. And it is an advantage of that scheme. Anyway, I'm interested to hear Bart's opinion of PowerShell, which is set to be the default shell for the Windows Console starting very soon. cmd.exe will still be available for a while, but I imagine in a couple of windows versions it will disappear entirely. I've little experience with PowerShell, so I don't know whether it will bring about a new level of argument interpretation that will get Bart all upset or if it will be the cat's meow. Some parts of it look awfully unix-like such as cat and nice looping constructs. Other parts bear little resemblance to anything I've used before. Seems a little verbose to me (it is a shell that wraps a complete object system). -- https://mail.python.org/mailman/listinfo/python-list
Re: When will they fix Python _dbm?
On Tuesday, December 6, 2016 at 9:35:19 PM UTC, Ian wrote: > On Mon, Dec 5, 2016 at 7:45 AM, clvanwall wrote: > > I have been a Perl programmer for 15+ years and decided to give Python a > > try. My platform is windows and I installed the latest 3.5.2. Next I > > decided to convert a perl program that uses a ndbm database since according > > to the doc on python, it should be able to work with it. Needless to say, > > I get: dbm.error: db type is dbm.ndbm, but the module is not available > > Searching on Python Bug Tracker shows _dbm missing back in 03-03-2012! > > That's a long time for a bug to be left open. > > Are you referring to http://bugs.python.org/issue14185? That's on > Linux platforms and it has to do with building Python, not using it. > > The dbm.ndbm documentation specifically says that it provides an > interface to the *Unix* ndbm library: > https://docs.python.org/3/library/dbm.html#module-dbm.ndbm. I don't > think that this module is part of the standard Windows distribution of > Python. You might be able to find a third-party distribution of the > module using a Windows port of ndbm, or you could try to build it > yourself. How about http://www.gnu.org/software/gdbm/gdbm.html Kindest regards. Mark Lawrence. -- https://mail.python.org/mailman/listinfo/python-list
Re: Detect Linux Runlevel
On 12/06/2016 03:29 PM, Marko Rauhamaa wrote: > Another thing is that, as stated before, the runlevel business is > legacy. It is still supported by systemd-update-utmp, but for how long > is anybody's guess. System V compatibility is still important to Linux, and as long as it is, something resembling a runlevel has to be provided, even it's just an abstraction of something else like a systemd target. So any system that advertises System V compliance or compatibility will have a runlevel. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
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 provide certain useful functions that Unix users value. If you don't want those functions, you're free to write your own shell that works however you want. Complaining that everyone *else* should want the same things you want is not reasonable. How does that work? Suppose I provide an assortment of applications that would work better if wildcards are expanded. Do I then have to provide one more application, a shell, to be run first if someone wants to run any of my applications? Which they then have to quit if they want to run some other programs that depend on wildcard expansion. (Actually at this point I haven't got a clue as to how Unix applications are distributed. I guess it's not as simple as just providing a binary executable. For the moment, I'm using C source code as every Unix system has a C compiler. I suppose it could be Python source too, but I doubt if my interpreters written in Python will run quite as briskly -- I find C slow enough for this purpose.) -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 12/06/2016 04:37 PM, BartC wrote: > How does that work? > > Suppose I provide an assortment of applications that would work better > if wildcards are expanded. > > Do I then have to provide one more application, a shell, to be run first > if someone wants to run any of my applications? Which they then have to > quit if they want to run some other programs that depend on wildcard > expansion. > > (Actually at this point I haven't got a clue as to how Unix applications > are distributed. I guess it's not as simple as just providing a binary > executable. For the moment, I'm using C source code as every Unix system > has a C compiler. I suppose it could be Python source too, but I doubt > if my interpreters written in Python will run quite as briskly -- I find > C slow enough for this purpose.) I'm not sure what your point is. If your app targets Windows, you'll need to support the filespec thing and do your own globbing because that's the only mechanism Windows provides. If your app targets unix, you'll probably want to do things the way unix users expect. If unix targets are important to you you take the time to learn about the environment in which you want your programs to run. -- https://mail.python.org/mailman/listinfo/python-list
Re: When will they fix Python _dbm?
On Dec 6, 2016 4:04 PM, wrote: On Tuesday, December 6, 2016 at 9:35:19 PM UTC, Ian wrote: > On Mon, Dec 5, 2016 at 7:45 AM, clvanwall wrote: > > I have been a Perl programmer for 15+ years and decided to give Python a try. My platform is windows and I installed the latest 3.5.2. Next I decided to convert a perl program that uses a ndbm database since according to the doc on python, it should be able to work with it. Needless to say, I get: dbm.error: db type is dbm.ndbm, but the module is not available > > Searching on Python Bug Tracker shows _dbm missing back in 03-03-2012! That's a long time for a bug to be left open. > > Are you referring to http://bugs.python.org/issue14185? That's on > Linux platforms and it has to do with building Python, not using it. > > The dbm.ndbm documentation specifically says that it provides an > interface to the *Unix* ndbm library: > https://docs.python.org/3/library/dbm.html#module-dbm.ndbm. I don't > think that this module is part of the standard Windows distribution of > Python. You might be able to find a third-party distribution of the > module using a Windows port of ndbm, or you could try to build it > yourself. How about http://www.gnu.org/software/gdbm/gdbm.html Well, that would be for dbm.gnu, not dbm.ndbm. And I don't see any distribution of the Python module there in any case. -- https://mail.python.org/mailman/listinfo/python-list
Re: Detect Linux Runlevel
On 2016-12-07 00:29, Marko Rauhamaa wrote: > Tim Chase : > > > This works based on my poking at it in both Py2 and Py3: > > Great info, Tim. > > A word a warning: your code doesn't lock /var/run/utmp before > access, which is a race condition. The file may be updated at any > time, and ordinary file reads may yield corrupted records. Since the code is reading in record-sized blocks and never writing, I'm not sure how much possibility there is for a race condition. At worst, I imagine that it would result in reading the old data which isn't a horrible condition. For under a certain block-size (PIPE_BUF, which I think used to be the minimum POSIX requirement of 512b, but is now 4096b on Linux), *nix operating systems were atomic in their reading and writing. So as long as the writer is writing a record at a time (or less) and not issuing multiple writes to update disjoint parts of the record, I'm pretty confident that atomicity won't be an issue for all intents and purposes. http://pubs.opengroup.org/onlinepubs/009695399/functions/write.html#tag_03_866_08 (though according to my "man 2 write" on my Linux box, before Linux 3.14, it wasn't atomic according to specs) > The library functions getutline(), pututline() etc lock the file > internally (although that is not documented). You can see the > (advisory record) locking in action by running the command C API functions which don't appear to be exposed in stock Python. ;-) > Another thing is that, as stated before, the runlevel business is > legacy. It is still supported by systemd-update-utmp, but for how > long is anybody's guess. Much like Unix itself, if the OP chooses to shoot off his own feet with them, my aim is to do it efficiently as requested. ;-) -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 06/12/2016 22:35, 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 That's the length of the command line, where parameters might still be in the form *.*, ie. pre-splitting and pre-expansion. After converting to argv format (which I believe is done by a C runtime function), that will be in different memory with presumably its own limits. (I'm assuming a null-terminator brings that to 8192, which is a weird 2**13). For Linux, as of kernal 2.6.25, apparently, the limit is 131072 bytes, an equally odd choice of 2**17 bytes. Maybe they started off at 4KB and 64KB but ran into problems. 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. I'm not sure if globs directly to commands bypass these restrictions, but I've seen real world issues with build systems with thousands of files that attempted to pass all dependencies to a target that blew up spectacularly (one of the reasons cl & link on windows accept argument files as input instead of just command line arguments). So does gcc on Linux (if you mean the @file syntax). It's a tidier way of doing things. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Tue, 6 Dec 2016 06:08 pm, Gregory Ewing wrote: >> And if there's an error in an option, you may have to abort, which means >> throwing away that list of files which, in some cases, can run into >> millions. > > This "millions of files" thing seems to be an imaginary > monster you've invented to try to scare people. I claim > that, to a very good approximation, it doesn't exist. > I've never encountered a directory containing a million > files, and if such a thing existed, it would be pathological > in enough other ways to make it a really bad idea. I didn't read Bart's "millions" as *literally* 2*10**6 or more, I read it as "a very large number of files". But it is conceivable that it is millions. ReiserFS can apparently handle up to approximately 4 billion files in a single directory; even FAT32 can take up to 268 million files in total, although there is a per-directory limit of 65535. Here's a true story of a fellow who ended up with 8 million files in a single directory: http://be-n.com/spw/you-can-list-a-million-files-in-a-directory-but-not-with-ls.html There are system dependent limits on globbing expansion and the number of arguments you can pass to a program: http://stackoverflow.com/questions/4185017/maximum-number-of-bash-arguments-max-num-cp-arguments http://www.in-ulm.de/~mascheck/various/argmax/ -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Tue, 6 Dec 2016 06:37 pm, Larry Hudson wrote: > On 12/05/2016 10:50 AM, BartC wrote: [...] >> One would be very annoyed if, reading a CSV file, where each of N values >> on a line correspond to a field of record, if one entry of "?LBC" >> expanded itself to a dozen entries, screwing everything up. >> > Now you're suggesting the _shell_ is going to read and process a CVS > file??? Be fair: he's giving an analogy. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Tue, Dec 6, 2016 at 3:05 PM, Random832 wrote: > > The fact that Windows was launched at boot by running "win.com" (either > in autoexec.bat or manually at the command line) created a *perception* > that windows ran "on top of DOS", but running it really *replaced* DOS > in memory, putting the CPU into protected mode and everything. The > ability to boot into (or exit to) DOS was because people still did real > work (and games) in DOS and the virtual environment of DOS-on-Windows > didn't perform well enough to be sufficient. Win16 (and Win32 if it thunked to Win16) called DOS INT 21h functions. The virtual machine manager implemented some (or most) of these functions in 32-bit protected mode (VxDs), but it had to maintain DOS data structures in each VM (e.g. drive working directories; PSPs). It was like an elaborate 32-bit DOS extender. Of course there was also a lot of new functionality for Win32 programs such as preemptively scheduled threads and memory-mapped files. > I vaguely remember a version of cmd.exe that would run on Windows > 98 floating around back in the day, but it certainly didn't come with > the OS. It might have been a pirated Windows NT component. cmd.exe was ported to Windows 9x, but never distributed with it. On Windows 9x it lacked Unicode support. Obviously all of the functions for NTVDM integration were omitted. Its `copy` command called CopyFile instead of NT's CopyFileEx, so you couldn't Ctrl+C cancel copying a large file. Reading from the console required custom support for command-line editing and history -- features that are built into the NT console. The command prompt would always wait for a child process to exit, even for GUI apps, because it couldn't call NT's NtQueryInformationProcess to get the PEB to peek at the subsystem type. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Wed, 7 Dec 2016 12:25 am, BartC wrote: > Or someone from Britain visiting the USA and saying OMG, everyone's got > a gun! Suppose someone runs amok and shoots everybody! Fun fact: there's a school shooting in the US about once a week. http://www.huffingtonpost.com.au/entry/school-shootings-since-newtown_n_5480209 The Washington Post does an analysis where they give all sorts of excuses why shootings on school grounds shouldn't be counted as school shootings. Here are some of the things that they don't think count as school shootings: - an adult couple shooting a cat on school grounds, who told police that they would have shot children if it had been "god's will"; - a gun that "went off" in a kindergarten student's backpack; - suicides; - gang-related shootings; - accidental discharges; etc. https://www.washingtonpost.com/news/fact-checker/wp/2015/06/29/has-there-been-one-school-shooting-per-week-since-sandy-hook/ In other words, if you ignore 90% of school shootings, you can dismiss concerns of school shootings as a lie. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 06Dec2016 23:37, BartC wrote: (Actually at this point I haven't got a clue as to how Unix applications are distributed. I guess it's not as simple as just providing a binary executable. Given that UNIX systems run on many many different processors, this has limited utility :-) For the moment, I'm using C source code as every Unix system has a C compiler. Feh. Obtainable, generally yes. Provided initially, not always. I suppose it could be Python source too, but I doubt if my interpreters written in Python will run quite as briskly -- I find C slow enough for this purpose.) Depends on the task. C does make for more performant code, but at the expense of higher programmer effort. I find Python fits many situations for me. Of course not _all_ situations. The performance trick with interpreted languages (shell, Python) is often to offload intensive things to special purpose noninterpreted components, be those separate executables or linked in libraries. Use the interpreted portion for orchestration and abstraction. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On 07Dec2016 01:55, BartC wrote: On 06/12/2016 22:35, 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 That's the length of the command line, where parameters might still be in the form *.*, ie. pre-splitting and pre-expansion. After converting to argv format (which I believe is done by a C runtime function), that will be in different memory with presumably its own limits. (I'm assuming a null-terminator brings that to 8192, which is a weird 2**13). For Linux, as of kernal 2.6.25, apparently, the limit is 131072 bytes, an equally odd choice of 2**17 bytes. Maybe they started off at 4KB and 64KB but ran into problems. I thought Linux had moved on to something more dynamic. Can't remember the citation though. 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. One might argue that this is exactly what command lines are to ease (either in the shell or in the app): expressing large things easily: cat *.txt # millions of files, anyone? I'm not sure if globs directly to commands bypass these restrictions, but I've seen real world issues with build systems with thousands of files that attempted to pass all dependencies to a target that blew up spectacularly (one of the reasons cl & link on windows accept argument files as input instead of just command line arguments). So does gcc on Linux (if you mean the @file syntax). It's a tidier way of doing things. Several things offer ways to read things-expected-to-be-large from files. Random example: wget will accept URLs from stdin or a file via its "-i" option, instead of always requiring them on the command line. The typical workaround on UNIX for large argument lists is xargs, though it does not fit all use cases. At some point I reach for (==> meaning "write") a small programme to work around such problems. Often a shell script or a python programme. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
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 see the similarity? No. The way they're used is entirely different. I get awfully tired of your constant pontificating about your opinions. Opinions based on facts: I've given a dozen examples where the shell's auto-expansion can screw things up. And I can easily come up with more, as have others in the thread. People's attitudes seem to be 'So don't that'. Or, 'So what?'. I'll repeat: They are OPINIONS and "they ain't gonna change nothin', no how, no way, not ever." MY opinion, which I fully accept "ain't gonna change nothin', no how, no way, not ever" is that for someone who claims to be such an expert and experienced programmer, your posts frequently show an amazing lack of knowledge. For example, quoting from another recent post of yours: >>Read the Python documentation for argparse > I just tried it, but it was too complex for me to set it up so as to discover with it did with * arguments. Your ignorance is clearly showing. Finally I have to admit that I'm an old codger and becoming more and more of a curmudgeon. This sometimes shows up in RL, but I generally try to avoid it in public forums like this, but occasionally...:-( [I suspect that there are others who share my opinion, however, whether that is true or not is entirely irrelevant as well.] That is also all I'm going to say on this subject, so don't bother responding to this post. I won't continue it. -- -=- Larry -=- -- https://mail.python.org/mailman/listinfo/python-list
Re: Detect Linux Runlevel
On Tue, 06 Dec 2016 09:45:05 -0700, Michael Torrie wrote: > I appreciate your measured response to what could be seen as an > inflammatory post. It was inflammatory and I considered a different response but after the knee jerking, I give it some thought and decided otherwise. The simple fact is I'm an outsider here. Over the last few months I have received some good advice and help from some good folks and for that I am grateful. I do not want to do anything that could jeopardize that. So I will try my best to keep my posts civil. And I thank you for your words. -- GNU/Linux user #557453 The cow died so I don't need your bull! -- https://mail.python.org/mailman/listinfo/python-list
Re: Detect Linux Runlevel
On Tue, 06 Dec 2016 13:06:35 -0600, Tim Chase wrote: > I forgot to mention that I want to include your name in the final script as a contributor, if that is ok. You will get a cut of the royalties. Lets see, how much is 20% of $0.00? Well, I'll let my account work that out as soon as she gets home from the grocery. -- GNU/Linux user #557453 The voices in my head may not be real but they have some good ideas. -- 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 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 configure > PowerShell to look different from the command prompt) If the console was started from a shortcut, then you're modifying the shortcut's console settings. If it was started in a new console by running an executable via Win+R or cmd's `start` command (e.g. `start powershell`), then the settings are persisted in a subkey of HKCU\Console. In this case, pinning the icon to the taskbar creates a new shortcut that uses the default config. You'll have to customize this pinned shortcut as well. -- https://mail.python.org/mailman/listinfo/python-list
Re: Detect Linux Runlevel
On 2016-12-06 21:27, Wildman via Python-list wrote: > On Tue, 06 Dec 2016 13:06:35 -0600, Tim Chase wrote: > I forgot to mention that I want to include your name in the > final script as a contributor, if that is ok. No issues here. > You will get a cut of the royalties. Lets see, how much is > 20% of $0.00? I'm not sure I'd settle for less than 25% of $0. ;-) -tkc -- https://mail.python.org/mailman/listinfo/python-list
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 weird
> 2**13).
I know strings in cmd.exe are limited to about 8K characters, so
that's probably the limit you observed. The Windows command line can
actually contain up to 65535 bytes. It's a sized UNICODE_STRING, which
uses a C unsigned short for the length. That's 32767 16-bit wide
characters, or 32766 sans the terminating NUL. For example:
parent:
>>> subprocess.call('python -ic " "' + ' a'*16375 + ' b')
child:
>>> import sys, win32api
>>> len(win32api.GetCommandLine())
32766
>>> sys.argv[:5]
['-c', 'a', 'a', 'a', 'a']
>>> sys.argv[-1]
'b'
>>> len(' '.join(sys.argv)) + len('python i " "')
32766
--
https://mail.python.org/mailman/listinfo/python-list
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 shell do globbing.
I want to pass a whole lot of file names to some obscure command. I don't
remember how that command deals with metacharacters, but it doesn't matter: I
just say
command fooba?.jpg {here,there}/*.jpg another/place/*.{png,jpg} [a-z]/IMG*
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:
- some might support * and ? but not {...}
- some might support SQL-like % and _
- some might insist on regular expressions instead of globs
- some might support the full set of globbing metacharacters, but have bugs
- some might not support any metacharacters
- some might not support ** for recursive wildcards
Don't say "they'll all call a library to do it for them", because even if such
a library exists, its not necessarily the case that everyone will use it, or
*want* to use it. There are always those who insist on doing things their own
way, for their own reasons:
https://www.xkcd.com/1168/
https://explainxkcd.com/wiki/index.php/1168:_tar
I can't easily know in advance what globbing rules I can use for a particular
command, but I can know what rules my shell uses, and now *all* commands
support the same, whether they know it or not.
--
Steven
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." - Jon Ronson
--
https://mail.python.org/mailman/listinfo/python-list
Re: Detect Linux Runlevel
Tim Chase : > On 2016-12-07 00:29, Marko Rauhamaa wrote: >> A word a warning: your code doesn't lock /var/run/utmp before >> access, which is a race condition. The file may be updated at any >> time, and ordinary file reads may yield corrupted records. > > Since the code is reading in record-sized blocks and never writing, > I'm not sure how much possibility there is for a race condition. At > worst, I imagine that it would result in reading the old data which > isn't a horrible condition. If you read a full record at an offset, you might be right. However, your code uses Python's buffered I/O: with open(utmp_fname, "rb") as f: while True: bytes = f.read(XTMP_STRUCT_SIZE) instead of os.open() and os.read(). > For under a certain block-size (PIPE_BUF, which I think used to be > the minimum POSIX requirement of 512b, but is now 4096b on Linux), > *nix operating systems were atomic in their reading and writing. That particular guarantee is true for pipes and FIFOs only. Marko -- https://mail.python.org/mailman/listinfo/python-list
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 provide certain useful functions that Unix >> users value. >> >> If you don't want those functions, you're free to write >> your own shell that works however you want. Complaining >> that everyone *else* should want the same things you >> want is not reasonable. > > How does that work? > > Suppose I provide an assortment of applications that would work better > if wildcards are expanded. > > Do I then have to provide one more application, a shell, to be run first > if someone wants to run any of my applications? Which they then have to > quit if they want to run some other programs that depend on wildcard > expansion. Your question is ambiguous. If we're talking about Greg's tongue-in-cheek suggestion that you write your own shell, then the answer is, it depends entirely on you. This bartshell that doesn't expand wildcards is your baby, doing what *you* want it to do. So its your decision. But I can tell you that by far the majority of Unix programs don't do their own globbing, or even offer it as an opt-in optional feature. Why would they need to? So if you want bartshell to be usable on Linux/Unix systems, you'll need some sort of opt-in setting to enable wildcard expansion. > (Actually at this point I haven't got a clue as to how Unix applications > are distributed. I guess it's not as simple as just providing a binary > executable. For the moment, I'm using C source code as every Unix system > has a C compiler. I suppose it could be Python source too, but I doubt > if my interpreters written in Python will run quite as briskly -- bash is about an order of magnitude slower than Python, and its still plenty fast enough for practical work. > I find C slow enough for this purpose.) http://www.catb.org/jargon/html/story-of-mel.html -- Steven "Ever since I learned about confirmation bias, I've been seeing it everywhere." - Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: Detect Linux Runlevel
Michael Torrie : > On 12/06/2016 03:29 PM, Marko Rauhamaa wrote: >> Another thing is that, as stated before, the runlevel business is >> legacy. It is still supported by systemd-update-utmp, but for how >> long is anybody's guess. > > System V compatibility is still important to Linux, and as long as it > is, something resembling a runlevel has to be provided, even it's just > an abstraction of something else like a systemd target. So any system > that advertises System V compliance or compatibility will have a > runlevel. I wonder if Linux still suffers from this local DoS: [ Now no-one else can log in ] This is a problem with advisory locking. The fact that anyone can create an exclusive lock on a file they can only read! Is this behavior appropriate? https://www.redhat.com/archives/linux-security/1996-Novembe r/msg00026.html> Didn't try it, but the utmp API seems hopeless in this regard. Marko -- https://mail.python.org/mailman/listinfo/python-list
[RELEASE] Python 3.6.0rc1 is now available
On behalf of the Python development community and the Python 3.6 release team, I'm excited to announce the availability of Python 3.6.0rc1. 3.6.0rc1 is the release candiate for Python 3.6, the next major release of Python. Code for 3.6.0 is now frozen. Assuming no release critical problems are found prior to the 3.6.0 final release date, currently 2016-12-16, the 3.6.0 final release will be the same code base as this 3.6.0rc1. Maintenance releases for the 3.6 series will follow at regular intervals starting in the first quarter of 2017. Among the new major new features in Python 3.6 are: * PEP 468 - Preserving the order of **kwargs in a function * PEP 487 - Simpler customization of class creation * PEP 495 - Local Time Disambiguation * PEP 498 - Literal String Formatting * PEP 506 - Adding A Secrets Module To The Standard Library * PEP 509 - Add a private version to dict * PEP 515 - Underscores in Numeric Literals * PEP 519 - Adding a file system path protocol * PEP 520 - Preserving Class Attribute Definition Order * PEP 523 - Adding a frame evaluation API to CPython * PEP 524 - Make os.urandom() blocking on Linux (during system startup) * PEP 525 - Asynchronous Generators (provisional) * PEP 526 - Syntax for Variable Annotations (provisional) * PEP 528 - Change Windows console encoding to UTF-8 * PEP 529 - Change Windows filesystem encoding to UTF-8 * PEP 530 - Asynchronous Comprehensions Please see "What’s New In Python 3.6" for more information: https://docs.python.org/3.6/whatsnew/3.6.html You can find Python 3.6.0rc1 here: https://www.python.org/downloads/release/python-360rc1/ Note that 3.6.0rc1 is still a preview release and thus its use is not recommended for production environments. More information about the release schedule can be found here: https://www.python.org/dev/peps/pep-0494/ -- Ned Deily n...@python.org -- [] -- https://mail.python.org/mailman/listinfo/python-list
