Michael Torrie :
> On 12/05/2016 04:37 PM, Marko Rauhamaa wrote:
>> Unfortunately, I am not wholly impressed by the end result. Mogadishu
>> has been replaced by Pyongyang. Some age-old Unix principles have been
>> abandoned without clear justification. For example, I was appalled to
>> find out t
On 12/05/2016 10:50 AM, BartC wrote:
And just what ARE A, C, and D?
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 parameters are separated by white-space and
commas, if a
parameter can contain white-space
Dennis Lee Bieber wrote:
-lm is not a valid file name on the OS's that use - as an option
prefix.
It's not invalid -- you can create a file called -lm
on a unix system if you want, you just have to be a bit
sneaky about how you refer to it:
% echo foo > ./-lm
% ls
-lm
% cat ./-lm
foo
Sane peo
BartC wrote:
But a similar example, suppose a syntax is:
appl *.* [options]
I would be disappointed by such a syntax. What if I want
to operate on two or more files with unrelated names? With
that syntax, I can't list them explicitly in the one command.
To make that possible, the syntax wou
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 defi
BartC wrote:
On 05/12/2016 19:29, Michael Torrie wrote:
On 12/05/2016 11:50 AM, BartC wrote:
So how do I do:
gcc *.c -lm
The -lm needs to go at the end.
Presumably it now needs to check each parameter seeing if it resembles a
file more than it does an option? And are options automati
On Tuesday 06 December 2016 14:57, Michael Torrie wrote:
> "-" is perfectly valid in a filename on Linux. Getting apps to recognize
> it as a filename and not an argument is another story. Convention is to
> allow an argument "--" that tells the arg parser that everything
> following that is not a
On Mon, 05 Dec 2016 21:42:52 -0600, Tim Chase wrote:
> On 2016-12-05 18:26, Wildman via Python-list wrote:
>> 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
On Mon, 05 Dec 2016 20:46:22 -0700, Michael Torrie wrote:
> On 12/05/2016 08:27 PM, Wildman via Python-list wrote:
>> On Mon, 05 Dec 2016 18:25:58 -0700, Michael Torrie wrote:
>>
>>> I think Python is a good choice for such a utility, but I agree it is
>>> much better to rely on these external ut
On 12/05/2016 07:25 PM, Dennis Lee Bieber wrote:
> On Mon, 5 Dec 2016 20:55:41 +, BartC declaimed
> the following:
>
>> This was a response to someone saying the wildcard param needs to
>> be at the end. There need be no such restriction if handled
>> properly (ie. no auto-expansion).
>>
> T
On 12/05/2016 08:27 PM, Wildman via Python-list wrote:
> On Mon, 05 Dec 2016 18:25:58 -0700, Michael Torrie wrote:
>
>> I think Python is a good choice for such a utility, but I agree it is
>> much better to rely on these external utilities as children to do the
>> platform-dependent work, rather
On 2016-12-05 18:26, Wildman via Python-list wrote:
> 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 wit
On 12/05/2016 07:48 PM, Steve D'Aprano wrote:
> On Tue, 6 Dec 2016 11:08 am, Michael Torrie wrote about systemd:
>
>> I have yet to see any evidence of this Pyonguang situation.
>
> Let me guess... you're running a single-user Linux box?
No I've done it on servers that weren't single-user (mail
On Mon, 05 Dec 2016 18:25:58 -0700, Michael Torrie wrote:
> I think Python is a good choice for such a utility, but I agree it is
> much better to rely on these external utilities as children to do the
> platform-dependent work, rather than try to re-implement everything in
> Python. A long time
OT, but I'm curious, do they explain *why* it's wrong and give an
alternative, or just outright deride it as "the wrong way". I ask because
I've read similar complaints about the community around systemd, but as it
rarely affects me personally, I've never bothered to care.
On Mon, Dec 5, 2016 at 8
Ifyou'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.
IIRC, command.com was a relic of Win9x
On Tue, 6 Dec 2016 11:08 am, Michael Torrie wrote about systemd:
> I have yet to see any evidence of this Pyonguang situation.
Let me guess... you're running a single-user Linux box?
Fortunately, I've managed to avoid needing to personally interact with
systemd at all. But over the last year or
On Tue, 6 Dec 2016 10:09 am, eryk sun wrote:
> On Mon, Dec 5, 2016 at 4:49 PM, Steve D'Aprano
> wrote:
>>
>> You've never used cmd.com or command.exe? "The DOS prompt"?
>
> The default Windows shell is "cmd.exe", and it's informally called the
> "Command Prompt",
Thanks for the correction, I a
Rather than argue about what is/should be allowed by a filesystem, this
defines what is allowed on NTFS (default for modern Windows systems):
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
One can complain about whether or not something should be allowed, but,
you'
On 12/05/2016 05:14 PM, 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.
>
>> I am a hobby programmer and I've been trying to learn python
>> for a few months now. The program i
will thid do? John
Sent from my Galaxy Tab® A
Original message From: justin walters
Date: 12/5/16 11:13 AM (GMT-06:00) To:
python-list@python.org Subject: Re: When will they fix Python _dbm?
On Mon, Dec 5, 2016 at 6:45 AM, clvanwall wrote:
> I have been a Perl programmer
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 'runleve
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.
> 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 m
On 12/05/2016 04:38 PM, Marko Rauhamaa wrote:
> Michael Torrie :
>> As I've gotten older I've learned the truth of this quotation:
>> "Those who do not understand UNIX are condemned to reinvent it, poorly."
>> -- Henry Spencer
>
> I thought you kinda liked systemd...
Yup I do.
--
https://mail.py
On 12/05/2016 04:37 PM, Marko Rauhamaa wrote:
> Unfortunately, I am not wholly impressed by the end result. Mogadishu
> has been replaced by Pyongyang. Some age-old Unix principles have been
> abandoned without clear justification. For example, I was appalled to
> find out that a systemd unit can b
Michael Torrie :
> As I've gotten older I've learned the truth of this quotation:
> "Those who do not understand UNIX are condemned to reinvent it, poorly."
> -- Henry Spencer
I thought you kinda liked systemd...
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Michael Torrie :
> On 12/05/2016 03:29 PM, Marko Rauhamaa wrote:
>> In fact, systemd is not an init system for Linux. Linux is the kernel of
>> the systemd operating system. Systemd is the
>>
>> One Ring to rule them all, One Ring to find them,
>>One Ring to bring them all and in the da
On Mon, 05 Dec 2016 15:39:24 -0700, Michael Torrie wrote:
> On 12/05/2016 03:34 PM, Wildman via Python-list wrote:
>> Too bad I don't speak C. I am an amateur programmer and most or all
>> my experience has been with assembly and various flavors of BASIC,
>> including VB and PowerBASIC. I did lo
On Mon, Dec 5, 2016 at 4:49 PM, Steve D'Aprano
wrote:
>
> You've never used cmd.com or command.exe? "The DOS prompt"?
The default Windows shell is "cmd.exe", and it's informally called the
"Command Prompt", not "DOS Prompt". In Windows 9x it was accurate to
say DOS prompt, since the shell was COM
On Tue, 6 Dec 2016 05:39 am, vmaha...@centerpointmedia.com wrote:
> Can someone help me print a generator object?
The same way as you print any other object:
print(obj) # Python 3
print obj # Python 2
But what you're actually asking for is a way to print the values produced by
the generator
On Monday December 5 2016 17:24, in comp.lang.python, "Chris Angelico"
wrote:
> On Tue, Dec 6, 2016 at 8:38 AM, Lew Pitcher
> wrote:
>> The OP asked for the runlevel, not the systemd target.
>
> Runlevels don't exist in systemd. And systemd targets don't exist in
> Upstart. The question "what r
On 12/05/2016 03:29 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Tue, Dec 6, 2016 at 8:38 AM, Lew Pitcher
>> wrote:
>>> The OP asked for the runlevel, not the systemd target.
>>
>> Runlevels don't exist in systemd. And systemd targets don't exist in
>> Upstart. The question "what runlevel
On 12/05/2016 03:34 PM, Wildman via Python-list wrote:
> Too bad I don't speak C. I am an amateur programmer and most or all
> my experience has been with assembly and various flavors of BASIC,
> including VB and PowerBASIC. I did look over the code but I guess
> I'm just a rebel without a clue.
On 12/05/2016 01:35 PM, BartC wrote:
>>> It seems shell language authors have nothing better to do than adding
>>> extra quirky features that sooner or later are going to bite somebody
>>> on the arse. Mainly I need a shell to help launch a program and give it
>>> some basic input; that's all.
>>
>
On Mon, 05 Dec 2016 23:59:48 +0200, Marko Rauhamaa wrote:
> Wildman :
>> Thanks but I knew about systemctl. As I already said my goal is to do
>> it without the use of an external program.
>
> Inspect:
>
>https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl.c>
>
> In p
Chris Angelico :
> On Tue, Dec 6, 2016 at 8:38 AM, Lew Pitcher
> wrote:
>> The OP asked for the runlevel, not the systemd target.
>
> Runlevels don't exist in systemd. And systemd targets don't exist in
> Upstart. The question "what runlevel are we in" does not make sense
> unless you're using an
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/lik
On Tue, Dec 6, 2016 at 8:38 AM, Lew Pitcher
wrote:
> The OP asked for the runlevel, not the systemd target.
Runlevels don't exist in systemd. And systemd targets don't exist in
Upstart. The question "what runlevel are we in" does not make sense
unless you're using an init system that works on the
Wildman :
> Thanks but I knew about systemctl. As I already said my goal is to do
> it without the use of an external program.
Inspect:
https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl.c>
In particular:
get_state_one_unit()
Then, proceed to:
https://dbus.freedes
On Monday December 5 2016 16:25, in comp.lang.python, "DFS"
wrote:
> On 12/05/2016 03:58 PM, Wildman 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 'runle
On Mon, 05 Dec 2016 16:25:56 -0500, DFS wrote:
> On 12/05/2016 03:58 PM, Wildman 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'.
>
>
> Why not
On 05/12/2016 19:29, Michael Torrie wrote:
On 12/05/2016 11:50 AM, BartC wrote:
So how do I do:
gcc *.c -lm
The -lm needs to go at the end.
Presumably it now needs to check each parameter seeing if it resembles a
file more than it does an option? And are options automatically taken
care
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'.
--
GNU/Linux user #557453
The cow died so I don't need your bull!
--
https://mail.python.org/mailman/listinfo/py
On 05/12/2016 19:48, Michael Torrie wrote:
Bored to day since it's -20 and I don't want to work outside.
On 12/05/2016 12:24 PM, BartC wrote:
(For example, in Windows:
>ren *.c *.d
Rename all .c files to .d files. None of the .d files exist (or, because
of the point below, some isolated
On 12/05/2016 01:09 PM, Random832 wrote:
> The rules are simpler than you're probably thinking of. There's actually
> no relationship between globs on the left and on the right. Globs on the
> left simply select the files to rename as normal, the glob pattern
> doesn't inform the renaming operation
Chris Angelico :
> On Tue, Dec 6, 2016 at 4:23 AM, Marko Rauhamaa wrote:
>> Bash is nice, too nice. It makes it easy to write code that's riddled
>> with security holes. The glorious Unix tradition is to ignore the
>> pitfalls and forge ahead come what may.
>
> Bash assumes that the person typing
On Mon, Dec 5, 2016, at 14:48, Michael Torrie wrote:
> Wow. Does that actually work? And work consistently? How would it
> handle globs like this:
The rules are simpler than you're probably thinking of. There's actually
no relationship between globs on the left and on the right. Globs on the
lef
In DFS writes:
> > Shells don't just repeat the characters you type, they interpret them.
> Yes, I see that now. I still don't think bash/shell should alter the
> input going to another program.
But that's one of the reasons *to* use a shell!
ls *.cERROR No file named
Bored to day since it's -20 and I don't want to work outside.
On 12/05/2016 12:24 PM, BartC wrote:
>> If it sees "*", it will try to open a file named "*".
>
> And people still say that the way Windows works is crazy!
>
> That's a valid
>> filename in Unix, but it should be avoided.
>
> No, i
On Tue, Dec 6, 2016 at 6:24 AM, BartC wrote:
>> If it sees "*", it will try to open a file named "*".
>
>
> And people still say that the way Windows works is crazy!
>
> That's a valid
>>
>> filename in Unix, but it should be avoided.
>
>
> No, it should be prohibited, if the file API and/or shel
On 12/05/2016 11:50 AM, BartC wrote:
> 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
> parameters are separated by white-space and commas, if a parameter can
> contain white-space or commas. That usually involv
On Tue, Dec 6, 2016 at 6:08 AM, Michael Torrie wrote:
> Agreed. I do this sort of trick all the time, even when I want to pass
> just a single file to a program. I often use expansion for paths as well:
>
> somecommand /path/to/somelongname*withendpart/myepisode*2x03*mp4
>
"somecommand" is "vlc"
On 5-12-2016 19:39, vmaha...@centerpointmedia.com wrote:
> On Wednesday, November 16, 2016 at 3:25:39 PM UTC-5, Peter Otten wrote:
>> vmaha...@centerpointmedia.com wrote:
>>
>>> I am running Python2.7, wherein I am running the following price of code:
>>>
>>> y = m.predict(input_fn=lambda:input_fn(
On 05/12/2016 18:34, eryk sun wrote:
On Mon, Dec 5, 2016 at 3:41 PM, BartC wrote:
Are you saying that if someone executes:
subprocess.Popen(["python","a.py", "*"])
the output will be: ['a.py','*']?
In that case forget Windows vs. Linux, you now have a program that will get
command paramet
On 12/05/2016 11:21 AM, Chris Angelico wrote:
> On Tue, Dec 6, 2016 at 5:02 AM, BartC wrote:
>> If the syntax is:
>>
>> program filespec
>>
>> or:
>>
>> program filespec file
>>
>> how do you tell whether the last file in an argument list is the optional
>> 'file', or the last file of the expa
On Monday December 5 2016 11:23, in comp.lang.python, "BartC"
wrote:
> On 05/12/2016 15:53, Chris Angelico wrote:
>> On Tue, Dec 6, 2016 at 2:41 AM, BartC wrote:
>>>
>>> Are you saying that if someone executes:
>>>
>>> subprocess.Popen(["python","a.py", "*"])
>>>
>>> the output will be: ['a.py
On Tue, Dec 6, 2016 at 5:50 AM, BartC wrote:
> So how do I do:
>
>gcc *.c -lm
>
> The -lm needs to go at the end.
>
> Presumably it now needs to check each parameter seeing if it resembles a
> file more than it does an option? And are options automatically taken care
> of, or is that something
On Mon, Dec 5, 2016 at 4:03 PM, Paul Moore wrote:
> 2. On Windows, the OS primitive takes a command line. The application is
> responsible for splitting it into arguments, if it wants to. Most do, for
> compatibility with the normal argv convention inherited via C from Unix. Many
> programs let t
On 05/12/2016 17:46, Dennis Lee Bieber wrote:
On Mon, 5 Dec 2016 11:42:08 +, BartC declaimed the
following:
And it doesn't work anyway; suppose I write:
>X A *.* C D
How does the program know when the expanded filenames of *.* end, and
the two extra parameters start? Remember it doesn
On Monday 05 December 2016 12:23:31 Marko Rauhamaa wrote:
> Chris Angelico :
> > On Tue, Dec 6, 2016 at 3:53 AM, Marko Rauhamaa
wrote:
> >> In recent years, I've been disillusioned with bash and started
> >> using Python more and more where I would previously have used bash.
> >> Python's explic
On Wednesday, November 16, 2016 at 3:25:39 PM UTC-5, Peter Otten wrote:
> vmaha...@centerpointmedia.com wrote:
>
> > I am running Python2.7, wherein I am running the following price of code:
> >
> > y = m.predict(input_fn=lambda:input_fn(df_predict), as_iterable=True)
> > print ('Predictions: {}'
On Mon, Dec 5, 2016 at 3:41 PM, BartC wrote:
>
> Are you saying that if someone executes:
>
> subprocess.Popen(["python","a.py", "*"])
>
> the output will be: ['a.py','*']?
>
> In that case forget Windows vs. Linux, you now have a program that will get
> command parameters processed differently
On Tue, Dec 6, 2016 at 5:02 AM, BartC wrote:
> If the syntax is:
>
> program filespec
>
> or:
>
> program filespec file
>
> 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 she
On 05/12/2016 16:49, Steve D'Aprano wrote:
On Mon, 5 Dec 2016 10:42 pm, BartC wrote:
So if someone types:
> X A B C
You would expect X to be launched, and be given arguments A, B and C.
Would I? I don't think so.
Even the DOS prompt supports some level of globbing. Its been a while sin
On Tue, Dec 6, 2016 at 4:23 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Tue, Dec 6, 2016 at 3:53 AM, Marko Rauhamaa wrote:
>>> In recent years, I've been disillusioned with bash and started using
>>> Python more and more where I would previously have used bash.
>>> Python's explicit synt
Chris Angelico :
> On Tue, Dec 6, 2016 at 3:53 AM, Marko Rauhamaa wrote:
>> In recent years, I've been disillusioned with bash and started using
>> Python more and more where I would previously have used bash.
>> Python's explicit syntax does automatically give you a level of
>> security, but I m
On Tue, 6 Dec 2016 02:41 am, BartC wrote:
> In that case forget Windows vs. Linux, you now have a program that will
> get command parameters processed differently depending on whether it was
> invoked from a shell or not.
Er, yeah? You say that as if it were a bad thing.
Look at it this way. Sup
On Mon, Dec 5, 2016 at 6: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,
On Mon, Dec 5, 2016 at 10:49 AM, Steve D'Aprano
wrote:
>
> In DOS, it might be the dir command itself. The disadvantage of the DOS way
> of doing this is that *every single command and application* has to
> re-implement its own globbing, very possibly inconsistently. That's a lot
> of duplicated w
On Tue, Dec 6, 2016 at 3:53 AM, Marko Rauhamaa wrote:
> In recent years, I've been disillusioned with bash and started using
> Python more and more where I would previously have used bash. Python's
> explicit syntax does automatically give you a level of security, but I
> must say the subprocess.P
Chris Angelico :
> On Tue, Dec 6, 2016 at 2:17 AM, Paul Moore wrote:
>> For a non-nerfed (but *radically* different to bash) Windows shell,
>> try Powershell. You'll probably hate it, but not because it's limited
>> in capabilities :-)
>
> Radically different from every shell I've ever called a
On Monday December 5 2016 10:41, in comp.lang.python, "BartC"
wrote:
> On 05/12/2016 15:05, Chris Angelico wrote:
>> On Tue, Dec 6, 2016 at 1:11 AM, BartC wrote:
>>>
>>> BTW what does Popen() do when one argument is '*.*'? Will that get
>>> expanded to multiple extra arguments, and at what point
On Mon, 5 Dec 2016 10:42 pm, BartC wrote:
> I don't know what a shell is. To me, it's some sort of user interface to
> the OS.
https://en.wikipedia.org/wiki/Unix_shell
You've never used cmd.com or command.exe? "The DOS prompt"? That's
(effectively) a shell.
Pedants may wish to explain exactly
On Tue, Dec 6, 2016 at 3:23 AM, BartC wrote:
> You still don't get point. I write a program P, a native executable. It
> takes command line parameters but exactly what it gets depends on whether
> it's started from a 'shell' or from inside another program? I don't want to
> worry about that stuff
On 05/12/2016 15:53, Chris Angelico wrote:
On Tue, Dec 6, 2016 at 2:41 AM, BartC wrote:
Are you saying that if someone executes:
subprocess.Popen(["python","a.py", "*"])
the output will be: ['a.py','*']?
In that case forget Windows vs. Linux, you now have a program that will get
command p
On Monday, 5 December 2016 15:41:59 UTC, BartC wrote:
> On 05/12/2016 15:05, Chris Angelico wrote:
> > On Tue, Dec 6, 2016 at 1:11 AM, BartC wrote:
> >>
> >> BTW what does Popen() do when one argument is '*.*'? Will that get expanded
> >> to multiple extra arguments, and at what point will it be
On Tue, Dec 6, 2016 at 2:41 AM, BartC wrote:
>
> Are you saying that if someone executes:
>
> subprocess.Popen(["python","a.py", "*"])
>
> the output will be: ['a.py','*']?
>
> In that case forget Windows vs. Linux, you now have a program that will get
> command parameters processed differently
What is your operating system, environment, and Python build?
dbm is just a module that might not have been included into your Python build.
It's not a bug but a deliberate choice of the package maker.
Regards,
Anton
> On 5 Dec 2016, at 17:45, clvanwall wrote:
>
> I have been a Perl
On 05/12/2016 15:05, Chris Angelico wrote:
On Tue, Dec 6, 2016 at 1:11 AM, BartC wrote:
BTW what does Popen() do when one argument is '*.*'? Will that get expanded
to multiple extra arguments, and at what point will it be expanded?
Nope. Popen is not a shell.
It sounds as if you want a nerf
On Tue, Dec 6, 2016 at 2:17 AM, Paul Moore wrote:
> For a non-nerfed (but *radically* different to bash) Windows shell, try
> Powershell. You'll probably hate it, but not because it's limited in
> capabilities :-)
>
Radically different from every shell I've ever called a shell. It
looks and fe
On Monday, 5 December 2016 14:11:34 UTC, BartC wrote:
> On 05/12/2016 12:23, Chris Angelico wrote:
> > On Mon, Dec 5, 2016 at 10:42 PM, BartC wrote:
> >> At least Windows does it properly. It doesn't even chop the command line
> >> into different parameters, making it considerably more flexible.
On Monday, 5 December 2016 15:06:05 UTC, Chris Angelico wrote:
> On Tue, Dec 6, 2016 at 1:11 AM, BartC wrote:
> >
> > BTW what does Popen() do when one argument is '*.*'? Will that get expanded
> > to multiple extra arguments, and at what point will it be expanded?
>
> Nope. Popen is not a shell
On Tue, Dec 6, 2016 at 1:11 AM, BartC wrote:
>
> BTW what does Popen() do when one argument is '*.*'? Will that get expanded
> to multiple extra arguments, and at what point will it be expanded?
Nope. Popen is not a shell.
It sounds as if you want a nerfed shell. Go ahead! I'm sure one
exists. I
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
On 05/12/2016 12:23, Chris Angelico wrote:
On Mon, Dec 5, 2016 at 10:42 PM, BartC wrote:
At least Windows does it properly. It doesn't even chop the command line
into different parameters, making it considerably more flexible. (Unless you
have a program based on a C-style main(nargs,args) entry
On Mon, Dec 5, 2016 at 10:42 PM, BartC wrote:
> At least Windows does it properly. It doesn't even chop the command line
> into different parameters, making it considerably more flexible. (Unless you
> have a program based on a C-style main(nargs,args) entry point where the C
> runtime will do thi
On 04/12/2016 23:25, Steve D'Aprano wrote:
On Mon, 5 Dec 2016 09:19 am, BartC wrote:
Command parameters /do/ behave differently between Windows and Linux,
for example try writing *.* as that third parameter.
In Windows, it will print *.*.
In Linux, if you have 273 files in the current directo
On Monday 05 December 2016 17:20, DFS wrote:
>>> Edit: I got it to work this way:
>>> column2="'R'"
>>>
>>> but that's bogus, and I don't want users to have to do that.
>>
>> (1) It's not bogus.
>
>
> It's extremely bogus. It's discarding part of my input.
When you type
name = 'Fred'
do you
88 matches
Mail list logo
