Tim Chase :
> Interesting. I read up on os.open() and os.read()
> https://docs.python.org/2/library/os.html#os.read
> but didn't notice anything there clarifying that it was unbuffered
> compared to the __builtins__.open() and fp.read() functions.
>
> Could you point me to resources where I can
On 2016-12-07 07:30, Marko Rauhamaa wrote:
> 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 re
Grant Edwards :
> There are a few things in Unix that are fundamentally broken and
> really just can't be used for the things they are intended for (serial
> ports come to mind).
>
> However, that doesn't seem to prevent them from having been used
> sucessfully that way way for 40 years. ;)
Sigh.
On 2016-12-07, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> Whereas if it were mandatory locking, enforced by the OS, it
>> wouldn't be a problem?
>
> The point is, the utmp scheme seems to be fundamentally broken. You
> can't use a regular file for this kind of communication.
There are a few t
Steven D'Aprano :
> Whereas if it were mandatory locking, enforced by the OS, it wouldn't
> be a problem?
The point is, the utmp scheme seems to be fundamentally broken. You
can't use a regular file for this kind of communication.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
On Wednesday 07 December 2016 18:08, Marko Rauhamaa wrote:
>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
>
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
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
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
>
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
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
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
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 resem
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 function
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'
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
expand
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 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 pricel
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
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
>> f
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 "wort
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 w
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 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 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
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 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
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: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 :
> 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 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 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
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
48 matches
Mail list logo
