In comp.lang.python, Thomas 'PointedEars' Lahn wrote:
> Michael Torrie wrote:
>> On 7/24/19 4:20 PM, Cameron Simpson wrote:
>>> That is some progress, hooray. Then there's just sbin -> bin to go.
>> I suppose in the olden days sbin was for static binaries, […]
> No, “sbin” is short for “*system*
On 24Jul2019 22:57, Dan Sommers <2qdxy4rzwzuui...@potatochowder.com> wrote:
On 7/24/19 10:24 PM, Michael Torrie wrote:
... In more recent times, binaries that are mostly applicable to the
super user go there. I don't see why you would want to merge those.
A normal user rarely has need of much
On 2019-07-25 03:57, Dan Sommers wrote:
On 7/24/19 10:24 PM, Michael Torrie wrote:
> ... In more recent times, binaries that are mostly applicable to the
> super user go there. I don't see why you would want to merge those.
> A normal user rarely has need of much in /sbin. Already /bin
On 7/24/19 10:24 PM, Michael Torrie wrote:
> ... In more recent times, binaries that are mostly applicable to the
> super user go there. I don't see why you would want to merge those.
> A normal user rarely has need of much in /sbin. Already /bin has way
> too much stuff in it (although I
On 24Jul2019 20:24, Michael Torrie wrote:
On 7/24/19 4:20 PM, Cameron Simpson wrote:
That is some progress, hooray. Then there's just sbin -> bin to go.
I suppose in the olden days sbin was for static binaries, usable in
single user mode for recovering the system without the main drive
On 7/24/19 4:20 PM, Cameron Simpson wrote:
> That is some progress, hooray. Then there's just sbin -> bin to go.
I suppose in the olden days sbin was for static binaries, usable in
single user mode for recovering the system without the main drive
mounted. In more recent times, binaries that are
On 24Jul2019 21:36, Barry Scott wrote:
On 23 Jul 2019, at 00:13, Cameron Simpson wrote:
Why _any_ modern system has anything other than /bin in the base
install escapes me. In the distant past /sbin and a distinct /usr
with its own bin had their values, but these days? Bah!
On fedora its
> On 23 Jul 2019, at 00:13, Cameron Simpson wrote:
>
> Why _any_ modern system has anything other than /bin in the base install
> escapes me. In the distant past /sbin and a distinct /usr with its own bin
> had their values, but these days? Bah!
On fedora its all in /usr these days with
On 23Jul2019 00:19, אורי wrote:
We are using `#!/usr/bin/env python`, for example on
https://github.com/speedy-net/speedy-net/blob/master/speedy/core/manage.py
For bash we are using `#!/usr/bin/env bash`. I don't know if those are the
best but they work.
Worthwhile. Plenty of platforms do
On 22Jul2019 21:14, Eli the Bearded <*@eli.users.panix.com> wrote:
In comp.lang.python, Tim Daneliuk wrote:
On 7/20/19 1:20 PM, Chris Angelico wrote:
> On Sun, Jul 21, 2019 at 4:13 AM Michael Speer wrote:
>> You may want to use `#!/usr/bin/env python3` instead.
I no longer have one to
We are using `#!/usr/bin/env python`, for example on
https://github.com/speedy-net/speedy-net/blob/master/speedy/core/manage.py
For bash we are using `#!/usr/bin/env bash`. I don't know if those are the
best but they work.
אורי
u...@speedy.net
On Sat, Jul 20, 2019 at 9:12 PM Michael Speer
In comp.lang.python, Tim Daneliuk wrote:
> On 7/20/19 1:20 PM, Chris Angelico wrote:
> > On Sun, Jul 21, 2019 at 4:13 AM Michael Speer wrote:
> >> You may want to use `#!/usr/bin/env python3` instead.
I no longer have one to verify, but I recall Solaris boxen used /bin/env
not /usr/bin/env.
>
On 7/20/19 4:28 PM, Brian Oney wrote:
> Why not make a compromise? What would be a potential pitfall of the
> following spitbang?
>
> #!python
Not sure this really changes the discussion.
--
https://mail.python.org/mailman/listinfo/python-list
On 21Jul2019 15:47, Peter J. Holzer wrote:
On 2019-07-21 09:04:43 +1000, Cameron Simpson wrote:
I'm with Tim Daneliuk. The environment matters and should be honoured
except
in extremely weird cases.
I don't think that all the scripts in /usr/bin are extremely weird
cases.
I think I'd
On 2019-07-21 10:26:17 -0500, Tim Daneliuk wrote:
> On 7/21/19 8:47 AM, Peter J. Holzer wrote:
> > That's fine. Unlike Tim I don't claim that anybody who disagrees with me
> > must be a newbie.
>
> Peter, that's ad hominem and unfair.
No, it isn't. Please read the first paragraph of
On Mon, Jul 22, 2019 at 1:36 AM Tim Daneliuk wrote:
>
> On 7/21/19 8:47 AM, Peter J. Holzer wrote:
> > That's fine. Unlike Tim I don't claim that anybody who disagrees with me
> > must be a newbie.
>
> Peter, that's ad hominem and unfair. I never said anything close to that.
> What I said is
On 7/21/19 8:47 AM, Peter J. Holzer wrote:
> That's fine. Unlike Tim I don't claim that anybody who disagrees with me
> must be a newbie.
Peter, that's ad hominem and unfair. I never said anything close to that.
What I said is that if someone were to spend an extended period of time
in devops
On 2019-07-21 09:04:43 +1000, Cameron Simpson wrote:
> On 21Jul2019 08:14, Chris Angelico wrote:
> > On Sun, Jul 21, 2019 at 5:26 AM Tim Daneliuk wrote:
> > > So, no, do NOT encode the hard location - ever. Always use env to
> > > discover the one that the user has specified. The only
On 2019-07-20 15:26:46 -0500, Tim Daneliuk wrote:
> On 7/20/19 2:56 PM, Peter J. Holzer wrote:
> > On 2019-07-20 14:11:44 -0500, Tim Daneliuk wrote:
> >> So, no, do NOT encode the hard location - ever. Always use env to
> >> discover the one that the user has specified. The only exception is
>
On 7/20/19, Michael Speer wrote:
>
> You may want to use `#!/usr/bin/env python3` instead.
This is partially supported in Windows, but only if .py files are
associated with the py.exe launcher and the shebang runs "python"
instead of "python3".
py.exe supports four builtin virtual commands:
On July 21, 2019 10:04:47 AM GMT+02:00, Manfred Lotz wrote:
>On Sun, 21 Jul 2019 10:21:55 +1000
>Cameron Simpson wrote:
>
>> On 21Jul2019 09:31, Chris Angelico wrote:
>> >On Sun, Jul 21, 2019 at 9:15 AM Cameron Simpson
>> >wrote: So you mean that a tool that depends on running on a
>>
On Sun, 21 Jul 2019 10:21:55 +1000
Cameron Simpson wrote:
> On 21Jul2019 09:31, Chris Angelico wrote:
> >On Sun, Jul 21, 2019 at 9:15 AM Cameron Simpson
> >wrote: So you mean that a tool that depends on running on a
> >consistent environment, it should use a shebang of
>
> On 21 Jul 2019, at 08:29, Christian Gollwitzer wrote:
>
> Am 21.07.19 um 07:31 schrieb Tim Daneliuk:
>> On 7/20/19 6:04 PM, Chris Angelico wrote:
>>> Are you aware of every systemwide command that happens to be
>>> implemented in Python, such that you won't execute any of them while
>>> you
Am 21.07.19 um 07:31 schrieb Tim Daneliuk:
On 7/20/19 6:04 PM, Chris Angelico wrote:
Are you aware of every systemwide command that happens to be
implemented in Python, such that you won't execute any of them while
you have the venv active?
No, but this has never been a problem because the
On Sun, Jul 21, 2019 at 3:41 PM Tim Daneliuk wrote:
>
> On 7/20/19 6:04 PM, Chris Angelico wrote:
> > Are you aware of every systemwide command that happens to be
> > implemented in Python, such that you won't execute any of them while
> > you have the venv active?
>
> No, but this has never been
On 7/20/19 6:04 PM, Cameron Simpson wrote:
> If you require a specific outcoming, set a specific environment. It is under
> your control. Control it.
Exactly right. I have just had the REALLY irritating experience of trying to
bootstrap a
location insensitive version of linuxbrew that mostly
On 7/20/19 6:04 PM, Chris Angelico wrote:
> Are you aware of every systemwide command that happens to be
> implemented in Python, such that you won't execute any of them while
> you have the venv active?
No, but this has never been a problem because the newer versions of
python tend to be pretty
On Sat, 20 Jul 2019 23:28:35 +0200
Brian Oney wrote:
> Why not make a compromise? What would be a potential pitfall of the
> following spitbang?
>
> #!python
I think that per definition a path in a shebang has to be absolute.
Actually, your suggestion won't work for people who use the fish
On 21Jul2019 09:31, Chris Angelico wrote:
On Sun, Jul 21, 2019 at 9:15 AM Cameron Simpson wrote:
So you mean that a tool that depends on running on a consistent
environment, it should use a shebang of "/usr/bin/python3.6" instead
of "/usr/bin/env python3"?
Jeez. No. That is the
On Sun, Jul 21, 2019 at 9:15 AM Cameron Simpson wrote:
>
> On 21Jul2019 08:14, Chris Angelico wrote:
> >On Sun, Jul 21, 2019 at 5:26 AM Tim Daneliuk wrote:
> >> So, no, do NOT encode the hard location - ever. Always use env to
> >> discover the one that
> >> the user has specified. The only
On 21Jul2019 08:14, Chris Angelico wrote:
On Sun, Jul 21, 2019 at 5:26 AM Tim Daneliuk wrote:
So, no, do NOT encode the hard location - ever. Always use env to discover the
one that
the user has specified. The only exception is /bin/sh which - for a variety of
reasons -
can reliably
On 7/20/19 5:47 PM, Tim Daneliuk wrote:
> On 7/20/19 5:14 PM, Chris Angelico wrote:
>> Using env for everything is a terrible idea and one that
>> will basically make virtual environments useless.
>
> Not if you manage them properly.
>
> Everyone's mileage is different, but when I enter a venv,
On Sun, Jul 21, 2019 at 8:56 AM Tim Daneliuk wrote:
>
> On 7/20/19 5:14 PM, Chris Angelico wrote:
> > Using env for everything is a terrible idea and one that
> > will basically make virtual environments useless.
>
> Not if you manage them properly.
>
> Everyone's mileage is different, but when I
On 7/20/19 5:14 PM, Chris Angelico wrote:
> Using env for everything is a terrible idea and one that
> will basically make virtual environments useless.
Not if you manage them properly.
Everyone's mileage is different, but when I enter a venv, I ensure everything I
do
there is packaged to work
On Sun, Jul 21, 2019 at 5:26 AM Tim Daneliuk wrote:
> So, no, do NOT encode the hard location - ever. Always use env to discover
> the one that
> the user has specified. The only exception is /bin/sh which - for a variety
> of reasons -
> can reliably counted upon.
A quick grep through my
On Sat, 2019-07-20 at 15:26 -0500, Tim Daneliuk wrote:
> On 7/20/19 2:56 PM, Peter J. Holzer wrote:
> > On 2019-07-20 14:11:44 -0500, Tim Daneliuk wrote:
> > > So, no, do NOT encode the hard location - ever. Always use env to
> > > discover the one that the user has specified. The only exception
On 7/20/19 2:56 PM, Peter J. Holzer wrote:
> On 2019-07-20 14:11:44 -0500, Tim Daneliuk wrote:
>> So, no, do NOT encode the hard location - ever. Always use env to
>> discover the one that the user has specified. The only exception is
>> /bin/sh which - for a variety of reasons - can reliably
On 2019-07-20 14:11:44 -0500, Tim Daneliuk wrote:
> So, no, do NOT encode the hard location - ever. Always use env to
> discover the one that the user has specified. The only exception is
> /bin/sh which - for a variety of reasons - can reliably counted upon.
>
> We don't need to bikeshed this.
On Sat, 20 Jul 2019 14:11:21 -0400
Michael Speer wrote:
> You may want to use `#!/usr/bin/env python3` instead.
>
In my case it doesn't matter. However, I agree that your suggestion is
usually preferable.
> There is a concept in python called the virtual environment. This
> used to be done
On 7/20/19 1:20 PM, Chris Angelico wrote:
> On Sun, Jul 21, 2019 at 4:13 AM Michael Speer wrote:
>>
>> You may want to use `#!/usr/bin/env python3` instead.
>>
>> There is a concept in python called the virtual environment. This used to
>> be done with a tool called virtualenv in python2, and is
On Sun, Jul 21, 2019 at 4:13 AM Michael Speer wrote:
>
> You may want to use `#!/usr/bin/env python3` instead.
>
> There is a concept in python called the virtual environment. This used to
> be done with a tool called virtualenv in python2, and is now done mainly
> through a venv module in
You may want to use `#!/usr/bin/env python3` instead.
There is a concept in python called the virtual environment. This used to
be done with a tool called virtualenv in python2, and is now done mainly
through a venv module in python3.
A virtual environment goes into a directory of your choosing
On Sun, 21 Jul 2019 03:44:24 +1000
Chris Angelico wrote:
> On Sun, Jul 21, 2019 at 3:41 AM Manfred Lotz
> wrote:
> >
> > Hi there,
> > Pretty new to python I've got a question regarding the proper
> > shebang for Python 3.
> >
> > I use
> >#!/usr/bin/python3
> >
> > which works fine.
> >
>
On Sun, Jul 21, 2019 at 3:41 AM Manfred Lotz wrote:
>
> Hi there,
> Pretty new to python I've got a question regarding the proper shebang
> for Python 3.
>
> I use
>#!/usr/bin/python3
>
> which works fine.
>
> Today I saw
>#!/usr/bin/python3 -tt
>
> and was wondering what -tt means.
>
>
Hi there,
Pretty new to python I've got a question regarding the proper shebang
for Python 3.
I use
#!/usr/bin/python3
which works fine.
Today I saw
#!/usr/bin/python3 -tt
and was wondering what -tt means.
Being on Fedora 30, Python 3.7.3 the man page of python3 doesn't even
mention
45 matches
Mail list logo
