@Zanna Where should it go? Should it just go immediately below the bit about sudo env PATH="$PATH" command?

Never mind...

@Zanna ...We still can't.

In versions of sudo that support --preserve-env=list, a command like

sudo VAR=val command...

can be replaced with

sudo --preserve-env=VAR command...

in situations where the value of VAR is val and VAR is an environment variable (rather than a shell variable that has not been exported).

Thus, for an environment variable VAR, one can use either of

sudo VAR="$VAR" command...
sudo --preserve-env=VAR command...

with the same effect.

But as you correctly said in that answer, the situation described in the question is not one in which

sudo VAR=val command...

ek@Cord:~$ command -v git-lsx
/home/ek/bin/git-lsx
ek@Cord:~$ git-lsx
fatal: not a git repository (or any of the parent directories): .git
ek@Cord:~$ sudo git-lsx
sudo: git-lsx: command not found
ek@Cord:~$ sudo -E git-lsx
sudo: git-lsx: command not found
ek@Cord:~$ sudo --preserve-env git-lsx  # same as sudo -E
sudo: git-lsx: command not found
ek@Cord:~$ sudo --preserve-env=PATH git-lsx  # stronger, but insufficient
sudo: git-lsx: command not found
ek@Cord:~$ sudo PATH="$PATH" git-lsx  # similarly insufficient

Ooh

@Zanna So if your answer is updated to cover --preserve-env=list, it should probably just be to explain that it's another thing that doesn't work.

When I tested --preserve-env=PATH I did so on a script in ~/.bin, which was not executable so I was calling bash to run it, but without the full path, like sudo --preserve-env=PATH bash script. Which runs bash with $PATH but still wouldn't work if bash were not in a secure_path location, I assume

@EliahKagan yeah

We have to call env

@Zanna In that case, bash performs the $PATH lookup according to its own rules.

Also, I'm not sure why bash does that and I kind of wish it didn't.

I believe this is unusual among interpreters, including shells, including Bourne-style shells.

Oh

ek@Cord:~$ command -v wrap
/home/ek/bin/wrap
ek@Cord:~$ wrap
Usage:  /home/ek/bin/wrap COMMAND [ARG...]
ek@Cord:~$ bash wrap
Usage:  wrap COMMAND [ARG...]
ek@Cord:~$ sh wrap
sh: 0: Can't open wrap
ek@Cord:~$ sh ~/bin/wrap
Usage:  /home/ek/bin/wrap COMMAND [ARG...]

Now I'm confused by the results of my test but I'm afk for now

When you get back, I will be eager to hear more, if you choose. :)

@Zanna I'd meant to ask you, but forgot -- did you end up starting anew with Python, as you'd been thinking of doing?

no :(

It occurs to me that, since you already know some Python, it may be better to approach learning (more) Python from the perspective of expanding outward from what you already know, rather than from the perspective of (re?)starting a whole new thing.

I don't think I know anything

You at least know how to use Python to do arithmetic, right?

(I think that's how the topic had come up when we discussed it before.)

I occurs to me that that message is somewhat ambiguous. My intention is to dispute the suggestion that you don't know any Python by asserting that you know some of it, based on your usage of python3 -c ... in shell scripts.

If someone interested in Bash knew only how to do arithmetic in it, in the context of arithmetic evaluation, then that would offer an only very limited handle on learning the rest of the language, because arithmetic evaluation in Bourne-style shells is its own sub-language where nothing works the same as it otherwise does.

But this is not so of most programming languages, and it is not so of Python. The general treatment of expressions in Python is the same as its treatment of arithmetic, just with more operators and types.

@EliahKagan haha yes when I want a calculator I start a python3 shell

Furthermore, unlike in many programming languages, exploring how one-line expressions are evaluated in Python is a common--possibly the most common--first major topic in presentations of the language. For example, this is the approach taken in Learning Python by Mark Lutz. (I am not recommending--nor disparaging--that book specifically, it's just the example that comes to my mind.)

I have another week here, some of which I could certainly spend trying to get started on something new

@Zanna Which operations do you use that for already?

@EliahKagan I was wondering why --preserve-env=PATH worked (my script ran) and -E didn't (Bash didn't find my script)

@EliahKagan (Please don't feel obligated to answer; for example, you might not feel like talking about Python at the moment.)

@Zanna Well, this shows the caller's path (rather than the reset path):

sudo --preserve-env=PATH printenv PATH

Are you wondering why that works when -E does not?

Or are you wondering why, in that usage, bash scriptname works like printenv PATH (and finds the script) rather than working like scriptname?

@EliahKagan no... except that I think -E is supposed to preserve PATH but for some reason does not. I mean I'm wondering why, if Bash is using its own rules for path lookup as you said, anything I did made any difference to it...

Oh. In:

bash scriptname

@EliahKagan oh only basic ones! I most commonly use it when I'm making planning drawings. I usually have to estimate some of the building dimensions by counting bricks on photographs (I hasten to add that these drawing are only to give an idea to the planning authority of what the building looks like and will look like after the alteration - nobody is going to build anything based on them)

@EliahKagan First bash tries to treat scriptname as a path, i.e., it looks for it in the current directory. If there is such a file in the current directory, it runs that, and $PATH is not searched.

Otherwise, it searches PATH for it.

Most interpreters don't do that second thing. bash does.

Assuming bash does not find it in the current directory, it uses PATH. Changing the value of PATH in the environment from which bash is started affects where it looks and what it finds.

@EliahKagan oh, ok. I do know that

When I said bash follows its own rules, that may have been misleading.

my attention has been scattered today

@Zanna Have you assigned to variables in Python?

(Assignment statements are not technically expressions in Python, but they are relevant to its use as a calculator.)

@Zanna No problem!

@EliahKagan At least as far as this conversation is concerned. :)

@Zanna so, say, I have counted 27 rows of bricks ("courses") and I know metric courses are 75mm high. I can't be bothered to work out 27x75 so I'll get Python to do it. Occasionally I need to do trigonometry and I don't know how to do that in Python so I use a calculator program

@EliahKagan :) other things were also ok.

:)

@Zanna If you are interested to use trigonometric functions in Python, they are provided in the math module.

yes, I'd like to be able to do that

>>> import math
>>> math.sin(math.pi / 2)
1.0
>>> math.sin(math.pi / 4)
0.7071067811865475

oooh :)

@EliahKagan doing tutorials, yes

You can also use from imports:

>>> from math import pi
>>> pi
3.141592653589793

That works whether or not the math module is first imported.

Or multiple names:

>>> from math import sin, cos, pi

from imports support * to import lots of stuff. This is discouraged when one writes a script/program and when one writes a module, but it's reasonable to do interactively when using Python as a calculator.

>>> from math import *

Note that from imports--even the * form--don't make the name math itself available. But you can still use import math to get it.

An example of when you might want to be able to write expressions that refer to the math module itself is if you want to list the things is provides.

You can do this with the dir builtin.

>>> import math
>>> dir(math)
['__doc__', '__loader__', '__name__', '__package__', '__spec__', 'acos', 'acosh', 'asin', 'asinh', 'atan', 'atan2', 'atanh', 'ceil', 'copysign', 'cos', 'cosh', 'degrees', 'e', 'erf', 'erfc', 'exp', 'expm1', 'fabs', 'factorial', 'floor', 'fmod', 'frexp', 'fsum', 'gamma', 'gcd', 'hypot', 'inf', 'isclose', 'isfinite', 'isinf', 'isnan', 'ldexp', 'lgamma', 'log', 'log10', 'log1p', 'log2', 'modf', 'nan', 'pi', 'pow', 'radians', 'remainder', 'sin', 'sinh', 'sqrt', 'tan', 'tanh', 'tau', 'trunc']

You can also try:

>>> help(math)

This works on individual functions too:

>>> help(math.sin)

Outside the Python interpreter (i.e., in a shell), you can use pydoc:

pydoc math

pydoc math.sin

Though you may prefer the online documentation.

@EliahKagan ooh neat!

Actually you should use pydoc3. Sorry.

pydoc3 math

pydoc3 math.sin

cool

I am not accustomed to using radians

sigh I need to learn some basic math

The less common trigonometric functions are not provided but you can define them in terms of the others. A more common situation in which I'd guess you might want to define your own functions is if you have a parameterized computation you want to do with multiple inputs.

@Zanna You can use math.degrees and math.radians to convert.

:)

You can also define your own functions that expect degrees (or that return them, for the inverse trigonometric functions), in terms of math.radians (or math.degrees) and the trigonometric functions.

You could even call them the same names (and don't use from imports).

(I have been asked to bake some cookies so I'll be back shortly!)

:)

>>> import math
>>> def sin(degs):
...     return math.sin(math.radians(degs))
...
>>> sin(45)
0.7071067811865475
>>> sin(90)
1.0
>>> sin(30)
0.49999999999999994
>>> sin(60)
0.8660254037844386

@EliahKagan haha you read my mind

the first thing I did was put in sin(30) and wonder why I didn't get anything like 0.5

some time ago we were looking at perdoc

now I know there's also pydoc

When using Python interactivelymas a calculator, especially for anything nontrivial or where you want to keep your work, you may want to use IPython.

You can--and likely would want to--have that installed locally, but you can also use it online.

@EliahKagan * interactively as

@Zanna perdoc?

Oh perldoc.

perldoc

sorry

this keyboard is too big for me XD

after 10 years of tiny netbook keyboards

You could use a small Bluetooth keyboard with your big-keyboarded laptop. :)

clearly I need that thing hahaha

@EliahKagan If you do that, and you have just a few functions you want defined, you can keep them in the notebook and run their definitions again.

But in general, the way to reuse your own Python functions (and types, when you make those) is to put them in a module.

@EliahKagan this is one of the many curiosity-inducing Python related things we sometimes get questions about

Are they getting answered?

sometimes

ek@Kip:~/source/repos$ mkdir trig
ek@Kip:~/source/repos$ cd trig
ek@Kip:~/source/repos/trig$ git init
Initialized empty Git repository in /home/ek/source/repos/trig/.git/
ek@Kip:~/source/repos/trig (master #)$ vim trig.py
ek@Kip:~/source/repos/trig (master #%)$ cat trig.py
"""trig.py - trigonometric functions in degrees"""

import math


def sin(x):
    """Returns the sine of x (measured in degrees)."""
    return math.sin(math.radians(x))
ek@Kip:~/source/repos/trig (master #%)$ python3
Python 3.6.8 (default, Oct  7 2019, 12:59:55)

The docstrings are optional. But they make the help builtin (and pydoc) work for your module.

The triple-quotes is not what makes them docstrings. They would be docstrings with regular quotes, too. But the common and recommended way to write docstrings is with """.

@EliahKagan wow awesome

Although this doesn't matter for very simple functions that you only use interactively, like trig.sin as defined above (in the use case you described), but Python will--by default--cache the intermediate representation (the bytecode) of any module you use, so that it may be faster to use next time. This goes in .pyc files. They should be created in __pycache__ directories--the Python interpreter creates them if they don't exist--but I sometimes get .pyc files in the current directory.

In either case, there is generally no good reason to synchronize .pyc files via source control, and you can put a pattern to ignore them into a .gitignore file in your repository.

Anyway, the specific implementation of docstrings is that they become the value of a __doc__ attribute on the module, class, or function they are written on.

ek@Kip:~/source/repos/trig (master #%)$ python3
Python 3.6.8 (default, Oct  7 2019, 12:59:55)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import trig
>>> trig.__doc__
'trig.py - trigonometric functions in degrees'
>>> trig.sin.__doc__
'Returns the sine of x (measured in degrees).'

This applies equally to docstrings in Python's standard library.

>>> import math
>>> math.__doc__
'This module is always available.  It provides access to the\nmathematical functions defined by the C standard.'
>>> math.sin.__doc__
'sin(x)\n\nReturn the sine of x (measured in radians).'

In Python, modules, types, and functions are things that can appear in an expression in the same way 3 or "hello" can appear in an expression.

One of the good things about this is that you can write "higher order" functions--functions that take functions as arguments and/or return functions.

For example:

def take_degrees(f):
    """Makes a function like f but that expects degrees instead of radians."""
    def g(x):
        return f(math.radians(x))

    return g

I'm going offline now, but I'll look again at this tomorrow afternoon or if not then definitely on Monday

Okay.

There is no hurry though. :)

I hope I can learn to do all my calculator things in Python! But even better if I can find some more fun uses for it

@EliahKagan Then you can use that function to define your degree-accepting sin function:

>>> from trig import take_degrees
>>> import math
>>> sin = take_degrees(math.sin)
>>> sin(30)
0.49999999999999994

I should really have called it taking_degrees instead of take_degrees.

@Zanna Python is handy but I often just use Wolfram|Alpha for calculations.

@EliahKagan That has the benefit that you can also use it--without having to repeat yourself--to define cos, tan, and whatever other functions you want to take degrees and have something for that is good except that it wants radians.