Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)
Op 11/03/2022 om 3:50 schreef Chris Angelico: On Fri, 11 Mar 2022 at 09:51, Cousin Stanley wrote: > The following will display a list of lxqt packages > that are in the repository and available to install > > apt-cache search lxqt | grep ^lxqt > Much faster: apt-cache pkgnames lxqt (apt-cache search will look for "lxqt" in descriptions too, hence the need to filter those out - apt-cache pkgnames is used by tab completion) Cousing Stanley's suggestion has the advantage that it also prints the short descriptions instead of just the package names. The packages names are often a bit too cryptic, I think. To search only in package names but still show the short description you could also --names-only instead of grep: apt-cache search --names-only lxqt or apt-cache search --names-only ^lxqt Chris, when you say "Much faster", do you mean faster to type or faster to execute? Your suggestion is certainly faster and easier to type. But as for execution speed: on my systems apt-cache search is fast enough that I don't really care about its execution time. When listing packages that is; tab completion is a different matter, where every delay can be quite annoying. -- "Don't Panic." -- Douglas Adams, The Hitchhiker's Guide to the Galaxy -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)
On Fri, 11 Mar 2022 at 19:57, Roel Schroeven wrote: > > Op 11/03/2022 om 3:50 schreef Chris Angelico: > > On Fri, 11 Mar 2022 at 09:51, Cousin Stanley > > wrote: > > > The following will display a list of lxqt packages > > > that are in the repository and available to install > > > > > > apt-cache search lxqt | grep ^lxqt > > > > > Much faster: > > > > apt-cache pkgnames lxqt > > > > (apt-cache search will look for "lxqt" in descriptions too, hence the > > need to filter those out - apt-cache pkgnames is used by tab > > completion) > > > Cousing Stanley's suggestion has the advantage that it also prints the > short descriptions instead of just the package names. The packages names > are often a bit too cryptic, I think. > > To search only in package names but still show the short description you > could also --names-only instead of grep: > > apt-cache search --names-only lxqt > > or > > apt-cache search --names-only ^lxqt > > Chris, when you say "Much faster", do you mean faster to type or faster > to execute? Your suggestion is certainly faster and easier to type. But > as for execution speed: on my systems apt-cache search is fast enough > that I don't really care about its execution time. When listing packages > that is; tab completion is a different matter, where every delay can be > quite annoying. Notably faster to execute on my system. Maybe the difference is insignificant on yours, but it's highly unlikely to be *slower*. The speed difference probably depends on how many package repositories you have, whether you have source packages, etc, etc, etc. (And of course, whether it's on a hard drive or SSD.) And what I would *actually* type is "apt i lxqt", so it's quite a lot faster. (I actually had to look up the precise command.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How to test input via subprocess.Popen with data from file
Op 10/03/2022 om 13:16 schreef Loris Bennett: Hi, I have a command which produces output like the following: Job ID: 9431211 Cluster: curta User/Group: build/staff State: COMPLETED (exit code 0) Nodes: 1 Cores per node: 8 CPU Utilized: 01:30:53 CPU Efficiency: 83.63% of 01:48:40 core-walltime Job Wall-clock time: 00:13:35 Memory Utilized: 6.45 GB Memory Efficiency: 80.68% of 8.00 GB I want to parse this and am using subprocess.Popen and accessing the contents via Popen.stdout. However, for testing purposes I want to save various possible outputs of the command as text files and use those as inputs. What format should I use to pass data to the actual parsing function? Is this a command you run, produces that output, and then stops (as opposed to a long-running program that from time to time generates a bunch of output)? Because in that case I would use subprocess.run() with capture_output=True instead of subprocess.Popen(). subprocess.run() returns a CompletedProcess instance wich has stdout and stderr members that contain the captured output as byte sequences or strings, depending on the parameters you passed. So in your case I would simply read the content of each text file as a whole into a string, and use subprocess.run() to get the command's output also as a string. Then you can have a parse function that accepts such strings, and works exactly the same for the text files as for the command output. Your parse function can then use splitlines() to access the lines individually. The data size is very small so it's not a problem to have it all in memory at the same time (i.e. no need to worry about trying to stream it instead). -- "Don't Panic." -- Douglas Adams, The Hitchhiker's Guide to the Galaxy -- https://mail.python.org/mailman/listinfo/python-list
Re: How to test input via subprocess.Popen with data from file
Op 11/03/2022 om 10:11 schreef Roel Schroeven:
Op 10/03/2022 om 13:16 schreef Loris Bennett:
Hi,
I have a command which produces output like the
following:
Job ID: 9431211
Cluster: curta
User/Group: build/staff
State: COMPLETED (exit code 0)
Nodes: 1
Cores per node: 8
CPU Utilized: 01:30:53
CPU Efficiency: 83.63% of 01:48:40 core-walltime
Job Wall-clock time: 00:13:35
Memory Utilized: 6.45 GB
Memory Efficiency: 80.68% of 8.00 GB
I want to parse this and am using subprocess.Popen and accessing the
contents via Popen.stdout. However, for testing purposes I want to save
various possible outputs of the command as text files and use those as
inputs.
What format should I use to pass data to the actual parsing function?
Is this a command you run, produces that output, and then stops (as
opposed to a long-running program that from time to time generates a
bunch of output)?
Because in that case I would use subprocess.run() with
capture_output=True instead of subprocess.Popen(). subprocess.run()
returns a CompletedProcess instance wich has stdout and stderr members
that contain the captured output as byte sequences or strings,
depending on the parameters you passed.
So in your case I would simply read the content of each text file as a
whole into a string, and use subprocess.run() to get the command's
output also as a string. Then you can have a parse function that
accepts such strings, and works exactly the same for the text files as
for the command output. Your parse function can then use splitlines()
to access the lines individually. The data size is very small so it's
not a problem to have it all in memory at the same time (i.e. no need
to worry about trying to stream it instead).
Very simple example:
import subprocess
from pprint import pprint
def parse(state_data):
lines = state_data.splitlines(keepends=False)
state_dict = {}
for line in lines:
key, value = line.split(': ')
state_dict[key] = value
return state_dict
def read_from_command():
return subprocess.run(['./jobstate'], capture_output=True,
check=True, encoding='UTF-8').stdout
def read_from_file(fn):
with open(fn, 'rt', encoding='UTF-8') as f:
return f.read()
pprint(parse(read_from_command()))
pprint(parse(read_from_file('jobfile')))
--
"Iceland is the place you go to remind yourself that planet Earth is a
machine... and that all organic life that has ever existed amounts to a greasy
film that has survived on the exterior of that machine thanks to furious
improvisation."
-- Sam Hughes, Ra
--
https://mail.python.org/mailman/listinfo/python-list
Invitation to join AuckPUG's virtual meeting on Testing
"The Alex to Zac of Testing" 0530~0730 UTC (1830~2030 NZDT), Wed 16Mar2022 Alex Znamensky (AuckPUG member) will introduce testing as a practice (what your training course didn't tell you about the real-world!). Zac Hatfield-Dodds will aim at more advanced users, talking about Property-Based testing and the Hypothesis library (https://hypothesis.readthedocs.io/en/latest/). Originally based at the Australian National University, he has recently moved and will come to us from San Francisco. We use a BigBlueButton-instance for web-conferencing. A recent web-browser and head-set should enable you to join us. No downloads/plug-ins etc. Further details including access instructions: https://www.meetup.com/NZPUG-Auckland/ or email me (off-list)... -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)
On Fri, 11 Mar 2022 at 06:38, Dan Stromberg wrote: > That's an attribute of your desktop environment, not the Linux distribution. > > EG: I'm using Debian with Cinnamon, which does support ctrl-alt-t. Never used Cinnamon. It comes from Mint, right? > Some folks say the desktop environment matters more than the distribution, > when choosing what OS to install. Yes, it's important. I switched from Ubuntu to Xubuntu (then Lubuntu) when Ubuntu started using Unity. I liked GNOME 2 and KDE prior to Plasma. They were simple, lightweight and effective. I found these qualities in XFCE and LXDE. Anyway I think I'll not install Debian, because it's LTS releases are not long enough for me. I don't know if there's a distro based on Debian that has a long LTS support, Ubuntu apart. -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)
On 3/11/22 11:03, Marco Sulla wrote: > Anyway I think I'll not install Debian, because it's LTS releases are > not long enough for me. I don't know if there's a distro based on > Debian that has a long LTS support, Ubuntu apart. Both Debian stable and Ubuntu LTS state they have a five year support life cycle. Ubuntu will support longer if you pay for it. Do you require more than five years? Anyway, use whatever works for you. -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)
On Fri, 11 Mar 2022 at 19:10, Michael Torrie wrote: > Both Debian stable and Ubuntu LTS state they have a five year support > life cycle. Yes, but it seems that official security support in Debian ends after three years: "Debian LTS is not handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success" https://wiki.debian.org/LTS This is the only problem for me. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to test input via subprocess.Popen with data from file
Why not just have scripts that echo out the various sets of test data you are interested in? That way, Popen would always be your interface and you wouldn't have to make two cases in the consumer script. In other words, make program that outputs test data just like your main data source program. Then the consumer would only have to work in one way. On 3/10/22 04:16, Loris Bennett wrote: Hi, I have a command which produces output like the following: Job ID: 9431211 Cluster: curta User/Group: build/staff State: COMPLETED (exit code 0) Nodes: 1 Cores per node: 8 CPU Utilized: 01:30:53 CPU Efficiency: 83.63% of 01:48:40 core-walltime Job Wall-clock time: 00:13:35 Memory Utilized: 6.45 GB Memory Efficiency: 80.68% of 8.00 GB I want to parse this and am using subprocess.Popen and accessing the contents via Popen.stdout. However, for testing purposes I want to save various possible outputs of the command as text files and use those as inputs. What format should I use to pass data to the actual parsing function? I could in both production and test convert the entire input to a string and pass the string to the parsing method. However, I could use something like test_input_01 = subprocess.Popen( ["cat test_input_01.txt"], stdout=subprocess.PIPE, ) for the test input and then pass a Popen object to the parsing function. Any comments on these alternative or suggestions for doing something completely different? Cheers, Loris -- https://mail.python.org/mailman/listinfo/python-list
Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)
Cousin Stanley wrote: >> apt-cache search lxqt | grep ^lxqt Chris Angelico wrote: > Much faster: > > apt-cache pkgnames lxqt > > apt-cache search will look for "lxqt" in descriptions too, > hence the need to filter those out > > apt-cache pkgnames is used by tab completion) > Thanks I didn't know about using pkgnames with apt-cache. -- Stanley C. Kitching Human Being Phoenix, Arizona -- https://mail.python.org/mailman/listinfo/python-list
