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
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 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 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
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 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
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 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 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
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 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
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 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 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 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 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
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 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
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 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 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
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, 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
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 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 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 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 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 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 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 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 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 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 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 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 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 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: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
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
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
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
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 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
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
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: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
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 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
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 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
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
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 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
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 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 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 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 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 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 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
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
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
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
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 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
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 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
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 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
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
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
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
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
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 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 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 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 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 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 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
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 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:
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
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
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
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
88 matches
Mail list logo
