[PLUG] a side note on browsers
Hello: Recently (the last 2 weeks) I have noticed a definite slow down in the 2 internet browsers I use (Opera and Firefox) I purposefully timed the start up of Mozilla Firefox this late afternoon, it took over 5 minutes before coming up, which is astonishing. I also tried Opera, it came up within about 9 seconds, but after I imported the bookmarks from Firefox, it then took about 19 seconds. I exported the Firefox bookmarks to an html file and was astonished to discover that for each bookmark, thousands of hex characters were being stored, the average is 1981 hex chars stored per book mark. Why is Firefox storing almost 2K hex characters per bookmark? After I imported the Firefox bookmarks into Opera (which required the installation of an Opera bookmarks extension application program) then Opera bringup slowed down significantly too. It was about 3 seconds and stretched out to 19 secs as I mentioned previously. Has anyone noticed the slow down? Why has Mozilla Firefox embedded almost 2K of hex code per bookmark? Has there been any feedback from the browser companies, as to what they are doing with book marks and why things are running slower than every before? Randall
[PLUG] question on locale change (with no notification)
Hello: Has anyone had their system locale setting changed after downloading a kernel update from one of the common linux distros? I had an upgrade to my openSuse Leap 15.5 and somehow the locale setting got changed to en_US.utf8. I went to do a grep on a set of files and then everything went super slow. I guessed that it was the locale setting and checked and sure enough, it had changed from "C" to "en_US.utf8" Just curious if this is happening to others after a kernel update? Randall
Re: [PLUG] asking for the simple bash command for tail
Correct, exact same message, but the -n option works. Maybe I need to do a careful manual read "man tail" ?? Randall On 5/5/24 11:41, David Fleck wrote: I suspect he's getting something like this: dcf@pop-os:~$ tail -1 myfiles* tail: option used in invalid context -- 1 -- - David Fleck On Sunday, May 5th, 2024 at 12:52 PM, Robert Citek wrote: What makes you say "does NOT work" ?
Re: [PLUG] asking for the simple bash command for tail
When I said does not work, I meant this owner@localhost: tail -1 hres* tail: option used in invalid context -- 1 using the -n option as "tail -n 1 hres*" does work as I need thank you for your replies. - Randall On 5/5/24 10:52, Robert Citek wrote: What makes you say "does NOT work" ? That is, what error message are you getting? Or how does the output you get differ from what you expect? Expanding on what Michael wrote, using the command below is similar to `tail -n1 myfiles*` but ensures `tail` only works on files ( not folders ), is able to handle filenames with spaces, and can handle large numbers of files. $ find ./. -maxdepth 1 -type f -name 'myfiles*' -print0 | xargs -0 tail -n 1 Regards, - Robert On Sun, May 5, 2024 at 10:30 AM Michael Ewan wrote: As previously noted, "tail -n 1 myfiles*" works. If you still want a Bash command line, here are a couple of options. The benefit of the first one is that tail does not print the names of the files. $ for f in myfiles*; do tail -1 $f; done $ find myfiles* | xargs tail -n 1# but this is totally like tail -n 1 myfiles* On Sun, May 5, 2024 at 8:00 AM American Citizen Hi: Does anyone know the bash command for getting the tail command to work correctly for a range of files, using the wild card character? tail -1 myfiles* does NOT work, but I do want the tail to run over the matched files in myfiles* Currently I am using ls myfiles* | sed "s/^/tail -1 /" > tmp ; bash tmp ; rm tmp but this is cumbersome. Thanks for showing a simple answer Randall
[PLUG] asking for the simple bash command for tail
Hi: Does anyone know the bash command for getting the tail command to work correctly for a range of files, using the wild card character? tail -1 myfiles* does NOT work, but I do want the tail to run over the matched files in myfiles* Currently I am using ls myfiles* | sed "s/^/tail -1 /" > tmp ; bash tmp ; rm tmp but this is cumbersome. Thanks for showing a simple answer Randall
[PLUG] sherloq - a digital image forensics tool
As an add-on to my current investigation of digital image forensics linux programs, I came across "Sherloq" by Guido Bertoli. Has anyone used this program? See https://eforensicsmag.com/sherloq-by-guido-bartoli/ - Randall
[PLUG] question about digital image forensics
Hello: I have been provided a digital image, but a careful forensic analysis is needed, to validate the authenticity of the picture. Is there anyone in PLUG who is familiar with validating digital images? Thank you for letting me know. - Randall
[PLUG] has anyone come across this problem? (and how to fix it?)
I have an HP Office Jet Pro 8600-N ink-jet printer, and used the HP Office Jet Device Management Program under linux. (HPLIP) to handle the print queue. Sometimes I sent a print job from a LibreOffice document to this printer, but forgot that my system is not currently connected to the LAN network, so naturally things halt and I get a message that the printer has been placed in "pause" mode and to reactivate it. Unfortunately, the printer configuration is written over and the "set default printer" checkbox is turned off and the printer is removed from default category. I am forced to go to the Yast2 manager and reedit the printer configuration and turn on the "make default printer" check box again. This is time consuming and it takes about 3 mins for the Yast2 program to run through all the printer drivers (must be thousands) Has anyone figured out how to avoid having the printer removed as default printer when the system is not connected to the LAN and a print command is issued? Randall
Re: [PLUG] something I am considering doing...
Paul: I tried to keep it simple on my end with just the ELF-64 file description. When I first saw all the scripts and other items pop-up under the category "executable" I was dismayed for awhile, but decided to keep it to that known file type which definitely IS an executable. This trimmed the files down from the 600K to the 14K or so (on my system) Randall On 3/25/24 07:19, Paul Heinlein wrote: On Sun, 24 Mar 2024, American Citizen wrote: Paul: Thanks for your post. Exactly what would you consider a valid statement for locating the executables? Finding executable files is not, to my mind, the same as find executable files for which I'd expect a man page. I'd suppose expect a man page for most occupants of * /bin * /usr/bin * /usr/sbin * /sbin Some denizens of /usr/libexec might warrant man pages too. One problem is that a lot of files in /usr/bin are symlinks or wrapper scripts; I'm not sure there's any "right" way to deal with them. Another problem is utilities that are often superceded by shell builtin commands. Most people don't run /usr/bin/test; they use the shell builtin 'test' or '['. So a man page for /usr/bin/test might be deceptive if its operations are not identical with those of your shell. Yet another problem is with schemes like /etc/alternatives that map a common utility name to a specific release. Different distributions handle alternatives differently; I don't have a suse system, so you'd need to look at your own setup to see what alternatives can be set there. I guess this is my long-winded way of saying that I'm not sure I know how I'd go about identifying "executables I should reasonably expect to have a man page" on my systems.
Re: [PLUG] something I am considering doing...
Paul: Thanks for your post. Exactly what would you consider a valid statement for locating the executables? Randall On 3/24/24 10:01, Paul Heinlein wrote: On Sat, 23 Mar 2024, American Citizen wrote: Paul: Good question from you. for executables I used $ find . -executable -print This is not a query I would expect to return accurate results because it will include files I would not consider candidates for man pages, including: * basic shared libraries ex: /usr/lib64/libsqlite3.so.0.8.6 * support scripts and libraries for interpreted languages ex: /usr/lib64/python3.11/smtpd.py * modules or subprograms for larger application suites ex: /usr/lib64/ImageMagick-6.9.12/modules-Q16/coders/jpeg.so * example scripts ex: /usr/share/git-core/templates/hooks/pre-push.sample * files given +x bits probably by mistake ex (CentOS 8): /usr/share/licenses/gd/COPYING Even the most conscientious developer wouldn't write man pages for files in those categories.
Re: [PLUG] trying to satisfy everyone's critiques on missing man pages for executables
On 3/24/24 07:55, Robert Citek wrote: zypper se --installed-only --format ta this failed too localhost:/ # zypper se -installed-only -format tabular | tee 000 The flag o is not known. localhost:/ # So do we have any script which works??
Re: [PLUG] trying to satisfy everyone's critiques on missing man pages for executables
I set this up at root location and tried to execute and got a stall
Actually I got this output
Usage: file [-bcEhikLlNnprsvzZ0] [--apple] [--extension]
[--mime-encoding] [--mime-type]
[-e testname] [-F separator] [-f namefile] [-m magicfiles]
file ...
file -C [-m magicfiles]
file [--help]
Usage: file [-bcEhikLlNnprsvzZ0] [--apple] [--extension]
[--mime-encoding] [--mime-type]
[-e testname] [-F separator] [-f namefile] [-m magicfiles]
file ...
file -C [-m magicfiles]
file [--help]
Can we find something which works?
On 3/23/24 22:41, Russell Senior wrote:
for i in $(echo $PATH | awk 'BEGIN { RS=":" } { print $0 }') ; do find $i
-type f -executable -print0 | xargs -0 file ; done | grep ELF | sort | uniq
| less
[PLUG] trying to satisfy everyone's critiques on missing man pages for executables
I am attempting to provide enough information on the missing man pages,
so I spent about 3 hours this evening on this.
I have a linux OpenSuse Leap 15.5 linux system. Running the zipper list
shows 7,443 installed programs for the software respositories
Here's the results of my investigations tonight
Bash script files:
1. find . -name * -type executable -print > exefiles
(resulted in a file with 653,455 lines) (done at root location
using root permission)
2. executing this bash script
file {"name"} > exefiles.1
NOTE: It took about 2 hours of work to get the bash script to
successfully complete due to unusual characters in the file name such
as pipe quotes tilde, etc. which kept blowing up the script file.
3. Selecting only ELF files from the file run creating exefiles.1 created:
37604 633501 8644870 exefiles.2
4. Carefully trimming the file narrowed to 18,068 executables (ELF-64)
18068 36157 420729 exefiles.3
5. There were actually only 14,383 unique file names, so obviously the
same executables are sprinkled on the whole hard disk in various folders.
localhost:/ # sort -u exefiles.3 | wc
14383 28775 328072
6. Run "man filename" on the exefiles.3 file results in
localhost:/ # wc exefiles.4
668085 5045286 39216490 exefiles.4
which consists of quite some script lines for certain man pages.
However checking "No manul entry for {executable}" results in
15,120 lines
This is 15120/18068 or 83.686% missing
I hope that this satisfies everyone's criteria
We are missing lots of man information at least on my machine. (and I
strongly suspect this is true of yours too)
Randall
Re: [PLUG] something I am considering doing...
To all readers: Maybe on determining missing man pages we should first define exactly what executables we mean? All ELF files? (not scripts?) etc? My initial determination was using strictly ELF files to look for the man pages from them Randall On 3/23/24 10:03, MC_Sequoia wrote: "I was surprised to find < 15% of the command executables were documented. Naturally I was hoping for something like 50% to 75%." I don't run Suze, but color me very suspicious. I did a quick Google search and found this thread about missing man pages. You might want to read through it. In summary, the user did a non-default install which was the cause of missing man pages. https://forums.opensuse.org/t/why-are-some-man-pages-missing/144164/8 -- Before relying on artificial intelligence to solve our problems, let's trying using intelligence first...
Re: [PLUG] something I am considering doing...
MC Sequoia I appreciate all the feedback I can get. Thank you for alerting me to this. Randall On 3/23/24 10:03, MC_Sequoia wrote: "I was surprised to find < 15% of the command executables were documented. Naturally I was hoping for something like 50% to 75%." I don't run Suze, but color me very suspicious. I did a quick Google search and found this thread about missing man pages. You might want to read through it. In summary, the user did a non-default install which was the cause of missing man pages. https://forums.opensuse.org/t/why-are-some-man-pages-missing/144164/8 -- Before relying on artificial intelligence to solve our problems, let's trying using intelligence first...
Re: [PLUG] something I am considering doing...
Robert:
As I am reading the replies back to the forum, now I come on your 2nd email
Thank you for this post.
I am going try to implement your script at the root level and see what
comes up
Randall
On 3/23/24 09:21, Robert Citek wrote:
I ask because I get very different results.
<<< ${PATH} tr : '\n' |
while read folder ; do
echo == ${folder}
find ${folder}/ -type f -executable |
rev |
cut -d / -f1 |
rev |
xargs -t -n1 man -w 2>&1 |
cat -n
done |
tee /tmp/file.list.man.txt
$ wc -l /tmp/file.list.man.txt
2863 /tmp/file.list.man.txt
$ grep -c 'No manual' /tmp/file.list.man.txt
114
$ echo $(( 114*1000/( 2863 / 2 ) ))
79
Using the above method, fewer than 8% do NOT have manual pages, i.e. 92% do
have man pages, which exceeds your original estimate of 50-75%. If nothing
else, it's a much smaller problem space for your AI project.
Regards,
- Robert
On Sat, Mar 23, 2024 at 9:48 AM Robert Citek wrote:
On Fri, Mar 22, 2024 at 6:04 PM American Citizen <
website.read...@gmail.com> wrote:
A few years ago, I took my Linux OS which is openSuse Leap v15.3 or so
and ran a check on the documentation such as the man1 through man9 pages
(run the %man man command to pull all this up) versus the actual
executables on the system.
I was surprised to find < 15% of the command executables were
documented. Naturally I was hoping for something like 50% to 75%.
Can you provide data to back up that assertion? For example, a script.
Regards,
- Robert
Re: [PLUG] something I am considering doing...
Robert
wow, asking me to start from scratch again
1. file . -executable -print (at root level with root permissions)
2. type {file names found} and save only the ELF executables
3. man executable name
This in short is what I did
Please be aware that 10,000's of executables will come up.
Randall
On 3/23/24 08:48, Robert Citek wrote:
On Fri, Mar 22, 2024 at 6:04 PM American Citizen
wrote:
A few years ago, I took my Linux OS which is openSuse Leap v15.3 or so
and ran a check on the documentation such as the man1 through man9 pages
(run the %man man command to pull all this up) versus the actual
executables on the system.
I was surprised to find < 15% of the command executables were
documented. Naturally I was hoping for something like 50% to 75%.
Can you provide data to back up that assertion? For example, a script.
Regards,
- Robert
Re: [PLUG] something I am considering doing...
Paul:
Good question from you.
for executables I used
$ find . -executable -print
at the root level "/" on my hard drive hosting the linux OS (using root
permissions)
Then I had to filter these by doing a
file {found name} to actually narrow to the executable
Example:
localhost:/home/owner/math/Diophantine/m-tuples # file nex
nex: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked, interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=a51414fed84b7f7c3229756342b3ae0b30abc182, for GNU/Linux
3.2.0, with debug_info, not stripped
I only consider the ELF executable as the actual file which needed
documentation.
Hope this answers your question?
Randall
On 3/23/24 08:24, Paul Heinlein wrote:
On Fri, 22 Mar 2024, American Citizen wrote:
A few years ago, I took my Linux OS which is openSuse Leap v15.3 or
so and ran a check on the documentation such as the man1 through man9
pages (run the %man man command to pull all this up) versus the
actual executables on the system.
I was surprised to find < 15% of the command executables were
documented. Naturally I was hoping for something like 50% to 75%.
If I am going to talk to an AI program, such as ChatBot or one of the
newer popular AI program and ask it to generate the documentation for
the complete OS, what AI chatbot would you choose?
My idea is to clue the AI program into the actual OS, then ask it to
finish documenting 100% of all the executables, or report to me all
executables which have no available documentation at all, period.
I'd be interested to know your definition of "command executables." Is
it everything in /bin, /usr/bin, /sbin, and /usr/sbin, with perhaps
/usr/libexec thrown in for good measure? If not, can you provide your
criteria for inclusion?
Presumably, you ruled out all hard and symbolic links, and you
accounted for documentation in Texinfo format, not just man pages.
I have no hands-on AI experience, but I do offer couple alternative
strategies that might assist:
First, try invoking each executable with common help options: -h,
--help, -?, or even 'help' itself. If there's good output, I suspect
you could pipe it into txt2man or a similar utility to generate a
basic man page.
Second, on rpm-based systems, the package might catalog other
documentation (likely, but not necessarily, in /usr/share/doc). The
shell-ish logic to unwrap this might be something like
for PROG in /usr/bin/* /usr/sbin/*; do
# rule out symlinks, though this is debatable
if test -L $PROG; then continue; fi
# see if rpm thinks a package owns $PROG
PKG=$(rpm -qf $PROG 2>/dev/null)
# if so, do a cursory look for documentation
if test -n "$PKG"; then
rpm -qd $PKG | grep -i $PROG
fi
done
The "grep" in there might be a bit limiting, but "rpm -qd" can be
quite verbose for some packages. Season to taste.
Re: [PLUG] something I am considering doing...
Okay, I get it, that AI is as only good as the input and if it is fed garbage, it can only spout garbage (wish that there was someway to clue the investors into this fact) On 3/22/24 17:51, Russell Senior wrote: On 3/22/24 17:39, Ben Koenig wrote: On Friday, March 22nd, 2024 at 5:04 PM, American Citizen wrote: A few years ago, I took my Linux OS which is openSuse Leap v15.3 or so and ran a check on the documentation such as the man1 through man9 pages (run the %man man command to pull all this up) versus the actual executables on the system. I was surprised to find < 15% of the command executables were documented. Naturally I was hoping for something like 50% to 75%. If I am going to talk to an AI program, such as ChatBot or one of the newer popular AI program and ask it to generate the documentation for the complete OS, what AI chatbot would you choose? My idea is to clue the AI program into the actual OS, then ask it to finish documenting 100% of all the executables, or report to me all executables which have no available documentation at all, period. This means the AI program would scour the internet for any and all documentation for each command, and there are 10,000's of executables to examine. (which is why I believe this is an AI task) Your thoughts? - Randall That would be an interesting experiment to see what it comes up with. I would question the results simply due to the quality of current LLM implementations. From recent anecdotal experience, I recently bought an expensive Logitech keyboard and it was behaving strangely so I tried to look up how to perform a "factory reset" for this model. The search results I found via DDG were interesting, there were multiple duplicate hits for what appeared to be a tech blog with generic instruction pages for my device. However there were multiple iterations of this page, for this keyboard model, each of which had instructions referencing physical features that do not exist on this actual keyboard. These appeared to be AI generated help pages that were clogging up actual search results. They were very well written, If I hadn't had the actual device in front of my I might have actually believed that there was a pinhole reset button next to the USB port. If you do this, you may need to find a way to define a "web of trust" that allows the AI to differentiate between human written articles, and AI written summaries. As it is right now, you might find yourself telling an AI to summarize help pages that are AI written summaries of AI written summaries of ( AI written summaries of ( AI written summaries of ( AI written summaries of (actual manuals) ) ) ) Recursion FTW! :) It seems inevitable that the AI serpent will stupidly eat its tail and devolve into even more of a stochastic septic tank than it is now. If I was an investor, I would be shorting hard into the AI bubble. To me, the only open question is whether humans get stupider faster than the machines.
Re: [PLUG] something I am considering doing...
Ben: You have touched on something very important here. For example I bought a brand new Logitech headphone, but suddenly found that my openSuse linux system could not support the acoustic dB volume that I was accustomed to in the past. An arduous search showed that the OS was not in sync with the newer Logitech firmware code for that headset. I had to play around sometime before I found a setting which restored the original volume levels. Please understand that Logitech was a bit on the defensive when I originally contacted them explaining my difficulties. I am not sure that the average person would have been able to satisfactorily resolve this. The key idea here is "web of trust". Randall On 3/22/24 17:39, Ben Koenig wrote: On Friday, March 22nd, 2024 at 5:04 PM, American Citizen wrote: A few years ago, I took my Linux OS which is openSuse Leap v15.3 or so and ran a check on the documentation such as the man1 through man9 pages (run the %man man command to pull all this up) versus the actual executables on the system. I was surprised to find < 15% of the command executables were documented. Naturally I was hoping for something like 50% to 75%. If I am going to talk to an AI program, such as ChatBot or one of the newer popular AI program and ask it to generate the documentation for the complete OS, what AI chatbot would you choose? My idea is to clue the AI program into the actual OS, then ask it to finish documenting 100% of all the executables, or report to me all executables which have no available documentation at all, period. This means the AI program would scour the internet for any and all documentation for each command, and there are 10,000's of executables to examine. (which is why I believe this is an AI task) Your thoughts? - Randall That would be an interesting experiment to see what it comes up with. I would question the results simply due to the quality of current LLM implementations. From recent anecdotal experience, I recently bought an expensive Logitech keyboard and it was behaving strangely so I tried to look up how to perform a "factory reset" for this model. The search results I found via DDG were interesting, there were multiple duplicate hits for what appeared to be a tech blog with generic instruction pages for my device. However there were multiple iterations of this page, for this keyboard model, each of which had instructions referencing physical features that do not exist on this actual keyboard. These appeared to be AI generated help pages that were clogging up actual search results. They were very well written, If I hadn't had the actual device in front of my I might have actually believed that there was a pinhole reset button next to the USB port. If you do this, you may need to find a way to define a "web of trust" that allows the AI to differentiate between human written articles, and AI written summaries. As it is right now, you might find yourself telling an AI to summarize help pages that are AI written summaries of AI written summaries of ( AI written summaries of ( AI written summaries of ( AI written summaries of (actual manuals) ) ) ) Recursion FTW! :) -Ben
[PLUG] something I am considering doing...
A few years ago, I took my Linux OS which is openSuse Leap v15.3 or so and ran a check on the documentation such as the man1 through man9 pages (run the %man man command to pull all this up) versus the actual executables on the system. I was surprised to find < 15% of the command executables were documented. Naturally I was hoping for something like 50% to 75%. If I am going to talk to an AI program, such as ChatBot or one of the newer popular AI program and ask it to generate the documentation for the complete OS, what AI chatbot would you choose? My idea is to clue the AI program into the actual OS, then ask it to finish documenting 100% of all the executables, or report to me all executables which have no available documentation at all, period. This means the AI program would scour the internet for any and all documentation for each command, and there are 10,000's of executables to examine. (which is why I believe this is an AI task) Your thoughts? - Randall
[PLUG] what is the best way to check an UPS unit for real battery capacity?
Hello Is there any way to check for battery capacity of the UPS unit without having to switch off the AC power input? Just curious if anyway while the UPS stays online can be done? Once I got caught with practically useless battery capacity (lead-acid cells) on an APC unit, because I had neglected to check the batteries capacity about once a year or so. I get a bit nervous when killing the AC power on a live system, although that's what the UPS is supposed to protect from. Is the best way to check done by killing the AC power? Randall
Re: [PLUG] problem encountered with argv[] change when a local file named "1" is inserted into the file system
Another person pointed out to me that the bash shell is making an escape
on hitting the brackets and trying to come up with a string match to the
files in the local directory, sort of like using the ls command "ls
*txt" to match on any txt file. I incorrectly assumed that the bracketed
group of characters was a string word, acting like a normal character set.
What is also interesting to me, is that this worked like a normal
character string and the bracketed characters were used exactly as they
were in the shell command, without interpretation in being passed to the
argv argument list.
Thanks again, Reid, for your reply.
Randall
On 12/16/23 13:04, American Citizen wrote:
Reid
Thank you for the reply. I could use quotes or tics or backslash the
brackets. I have not encountered this problem before, where a file
named "1" would cause the problem and I am still curious as to why and
how the shell picked up the file name as apparently what is inside the
brackets doesn't seem to stop this odd behavior, I changed the inside
to [1,2,3,4,5] for example, but the program still crashed. I noticed
that [20,20,20,20,20] and [30,30,30,30,30] also works fine, apparently
the first two characters of "[1" trigger this reaction when the file
"1" exists in the local directory.
Randall
On 12/16/23 11:35, Reid wrote:
Sent with Proton Mail secure email.
On Saturday, December 16th, 2023 at 11:26 AM, American Citizen
wrote:
Hello:
I bumped into a curious problem with the argv variables changing,
when a
certain file named "1" is added into the local directory of the
executable.
Here is the test file, a simple program named test.c
#include
#include
int main(int argc, char **argv) {
int i=1;
//int STDIN = 1;
char INCURV[1024] = {'\0'};
while(i
I compile this file as
% gcc -o wack test.c -ggdb
(it is too easy to wipe out the source file if the object name almost
matches)
gcc is gcc version 7.5.0 (SUSE Linux)
I have the gdb debugger stop on line 13 "printf("we are here\n");"
Using input to the command:
% wack -arderivs -curve [0,0,0,-1156,0]
when no file named "1" exists in the directory then argv looks okay
argv[0] = "/../../wack"
argv[1] = "-arderivs"
argv[2] = "-curve"
argv[3] = "[0,0,0,-1156,0]"
argv[4] = 0x0
which is all fine and well.
I used the touch command to create file "1" in the local directory
% touch 1
and restart the gdb debugger.
argc count = 4 as expected
but argv[3] = "1"
Is this a bug in c?
Why is argv[3] changed?
It's a shell issue, not a C issue. The shell is interpreting
something in the square-bracketed argument as special characters. To
avoid it, put the argument in quotes.
(gdb) r -arderivs -curve 1
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /tmp/wack -arderivs -curve 1
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Demo:
(gdb) r -arderivs -curve [0,0,0,-1156,0]
...
Breakpoint 1, main (argc=4, argv=0x7fffd568) at test.c:6
6 int i=1;
(gdb) p argv[3]
$8 = 0x7fffd99f "1"
(gdb) r -arderivs -curve "[0,0,0,-1156,0]"
...
Breakpoint 1, main (argc=4, argv=0x7fffd558) at test.c:6
6 int i=1;
(gdb) p argv[3]
$9 = 0x7fffd991 "[0,0,0,-1156,0]"
Randall
Re: [PLUG] problem encountered with argv[] change when a local file named "1" is inserted into the file system
Reid
Thank you for the reply. I could use quotes or tics or backslash the
brackets. I have not encountered this problem before, where a file named
"1" would cause the problem and I am still curious as to why and how the
shell picked up the file name as apparently what is inside the brackets
doesn't seem to stop this odd behavior, I changed the inside to
[1,2,3,4,5] for example, but the program still crashed. I noticed that
[20,20,20,20,20] and [30,30,30,30,30] also works fine, apparently the
first two characters of "[1" trigger this reaction when the file "1"
exists in the local directory.
Randall
On 12/16/23 11:35, Reid wrote:
Sent with Proton Mail secure email.
On Saturday, December 16th, 2023 at 11:26 AM, American Citizen
wrote:
Hello:
I bumped into a curious problem with the argv variables changing, when a
certain file named "1" is added into the local directory of the executable.
Here is the test file, a simple program named test.c
#include
#include
int main(int argc, char **argv) {
int i=1;
//int STDIN = 1;
char INCURV[1024] = {'\0'};
while(i
I compile this file as
% gcc -o wack test.c -ggdb
(it is too easy to wipe out the source file if the object name almost
matches)
gcc is gcc version 7.5.0 (SUSE Linux)
I have the gdb debugger stop on line 13 "printf("we are here\n");"
Using input to the command:
% wack -arderivs -curve [0,0,0,-1156,0]
when no file named "1" exists in the directory then argv looks okay
argv[0] = "/../../wack"
argv[1] = "-arderivs"
argv[2] = "-curve"
argv[3] = "[0,0,0,-1156,0]"
argv[4] = 0x0
which is all fine and well.
I used the touch command to create file "1" in the local directory
% touch 1
and restart the gdb debugger.
argc count = 4 as expected
but argv[3] = "1"
Is this a bug in c?
Why is argv[3] changed?
It's a shell issue, not a C issue. The shell is interpreting something in the
square-bracketed argument as special characters. To avoid it, put the argument
in quotes.
(gdb) r -arderivs -curve 1
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /tmp/wack -arderivs -curve 1
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Demo:
(gdb) r -arderivs -curve [0,0,0,-1156,0]
...
Breakpoint 1, main (argc=4, argv=0x7fffd568) at test.c:6
6 int i=1;
(gdb) p argv[3]
$8 = 0x7fffd99f "1"
(gdb) r -arderivs -curve "[0,0,0,-1156,0]"
...
Breakpoint 1, main (argc=4, argv=0x7fffd558) at test.c:6
6 int i=1;
(gdb) p argv[3]
$9 = 0x7fffd991 "[0,0,0,-1156,0]"
Randall
[PLUG] problem encountered with argv[] change when a local file named "1" is inserted into the file system
Hello:
I bumped into a curious problem with the argv variables changing, when a
certain file named "1" is added into the local directory of the executable.
Here is the test file, a simple program named test.c
#include
#include
int main(int argc, char **argv) {
int i=1;
//int STDIN = 1;
char INCURV[1024] = {'\0'};
while(i
I compile this file as
% gcc -o wack test.c -ggdb
(it is too easy to wipe out the source file if the object name almost
matches)
gcc is gcc version 7.5.0 (SUSE Linux)
I have the gdb debugger stop on line 13 "printf("we are here\n");"
Using input to the command:
% wack -arderivs -curve [0,0,0,-1156,0]
when no file named "1" exists in the directory then argv looks okay
argv[0] = "/../../wack"
argv[1] = "-arderivs"
argv[2] = "-curve"
argv[3] = "[0,0,0,-1156,0]"
argv[4] = 0x0
which is all fine and well.
I used the touch command to create file "1" in the local directory
% touch 1
and restart the gdb debugger.
argc count = 4 as expected
but argv[3] = "1"
Is this a bug in c?
Why is argv[3] changed?
Randall
Re: [PLUG] strange system behavior - inotify problem?
Hello everyone: Yesterday afternoon was quite interesting as piece by piece I turned off the executing programs, but the random sleep pattern remained. I even stripped all of akonadi from my system, as I didn't want to wade through a mess. FInally I started killing all my magma programs .. 1 by 1. Nothing changed. I did notice that as I terminated running programs the disk access light started flashing faster and faster (repetitively) I finally killed a reliable C program that I had running in the background for many years (as I am able on a live system) and when I killed that program, the disk access light suddenly started blinking like a warning light, very repetitive, like a flasher. At this point I began to wonder if perhaps one of my disk drives were failing, so I patched the system to latest levels and then backed up everything all the while hoping that if a disk crash was impending, I've be able to save most everything. The updates and backups went fine. Well, the disks are okay, I went to the smart monitor section and the 3 drives are healthy. I rebooted twice and the problem seems to have disappeared. I still am wondering what brought all this on? Randall On 12/2/23 11:40, Ted Mittelstaedt wrote: I suspect a clue to your issue is in your post, - see the following: https://stackoverflow.com/questions/639540/how-much-memory-can-a-32-bit-process-access-on-a-64-bit-operating-system I suspect that somewhere in that mess you might have a program that's not 64 bit clean. Just for grins try defining an 8GB ramdrive as your swapfile and I'll bet the freezing disappears. Ted -Original Message- From: PLUG On Behalf Of American Citizen Sent: Saturday, December 2, 2023 10:53 AM To: Portland Linux/Unix Group Subject: [PLUG] strange system behavior - inotify problem? Hello: I have a very interesting problem occurring my opensuse Leap 15.5 linux system. I am crunching number theory modules, using magma to do descents on elliptic curves. I do open a new konsole screen and do a tail on the magma results, in real time. There are 6 magma programs executing in this way at the same time. I also have 3 monitoring programs, but they are set up as a bash script file with a while [ 1 ] loop, but each has a sleep nnn seconds at the end of the loop. I was getting occasionally the tail warning message, no files left for tail, using polling instead. I installed the inotify-comment bash script from the stackexchange web page https://unix.stackexchange.com/questions/15509/whos-consuming-my-inotify-resources. Running this script does not show anything unusual, I am only using 402 watches in 131 instances. I did up the values in the sysctl.conf file to large sizes, so I don't suspect that the problem is caused by this. The system strangely halts the start of a new process, for up to 20 secs at a time, for example, I tried to open up a new Konsole screen and the window opens up, but then sits there for a period of time before completing the interior of the screen. Another example, while typing this email, I made a mistake and had to back up, the moment I hit the backspace key, everything froze for about 10 secs or so, before resuming. Third example, one of my monitoring screens suddenly went into uninterruptable mode, trying using control-C did not work, I had to terminate the Konsole screen and restart the bash script over again in a new window. Right now I don't know quite what to do? This is slowing things way down for me, while the system seems fine, I am only using 4 gigs of the 32 gigs system RAM, so that should not be a problem. Puzzled - Randall
[PLUG] strange system behavior - inotify problem?
Hello: I have a very interesting problem occurring my opensuse Leap 15.5 linux system. I am crunching number theory modules, using magma to do descents on elliptic curves. I do open a new konsole screen and do a tail on the magma results, in real time. There are 6 magma programs executing in this way at the same time. I also have 3 monitoring programs, but they are set up as a bash script file with a while [ 1 ] loop, but each has a sleep nnn seconds at the end of the loop. I was getting occasionally the tail warning message, no files left for tail, using polling instead. I installed the inotify-comment bash script from the stackexchange web page https://unix.stackexchange.com/questions/15509/whos-consuming-my-inotify-resources. Running this script does not show anything unusual, I am only using 402 watches in 131 instances. I did up the values in the sysctl.conf file to large sizes, so I don't suspect that the problem is caused by this. The system strangely halts the start of a new process, for up to 20 secs at a time, for example, I tried to open up a new Konsole screen and the window opens up, but then sits there for a period of time before completing the interior of the screen. Another example, while typing this email, I made a mistake and had to back up, the moment I hit the backspace key, everything froze for about 10 secs or so, before resuming. Third example, one of my monitoring screens suddenly went into uninterruptable mode, trying using control-C did not work, I had to terminate the Konsole screen and restart the bash script over again in a new window. Right now I don't know quite what to do? This is slowing things way down for me, while the system seems fine, I am only using 4 gigs of the 32 gigs system RAM, so that should not be a problem. Puzzled - Randall
Re: [PLUG] Question: grabbing only 1 file using wget
Hi, appreciate the reply I decided to go with the Curl response and technique of grabbing the index.js file. I also believe I am close to talking with the site administrator, so things are all out in the open. While Iceland earthquake lists seem to be common, only the vafri.is site has the focal mechanisms, which are key to understanding what is going on. I am trying to get this data released in a csv file format On 11/21/23 10:11, King Beowulf wrote: On 11/20/23 13:29, American Citizen wrote: Hello: I am trying to grab one specific file from a quake monitoring website using wget. The file name is "index.js" The wget command is % wget -r -l3 --no-parent -A "index.js" https://vafri.is/quake/ However the results do NOT come back with the file at all, but apparently the wget command is deflected and unable to retrieve the file. I can do a manual save of the website as an html file with an html directory which contains the "index.js" file. What am I doing wrong? Thank you for the clarification/correction and advice. Why try to spider the site and run afoul of there rebots.txt? If the file is publicly accessible just use wget https://vafri.is//index.js see 'man wget' for options to compensate for URL redirects etc. -Ed
Re: [PLUG] playing around with the wget command finally worked
John's solution works perfect for me, I opened up Firefox, went to tools, network tab, and reloaded. Lots of stuff flew by, but found the index.js file. Did a copy by Curl command and put it in my bash script. Works perfectly, timestamping the received file and created a timestamped csv file too. Randall
Re: [PLUG] playing around with the wget command finally worked
I am making a good faith effort to contact the site administrators. What is ironic is that anyone can use the save page command in the standard browser tools and get the file that way without asking at all. On 11/20/23 13:58, American Citizen wrote: At the risk of being blocked by the Skalfti website, I found that the following wget command grabs one and only one file %wget -r -A 'index.js' -e robots=off -O index.js https://vafri.is/quake/ Notice that I had to give the file a name using the -O option, and it is stored in the current working directory. I read that using the option -e robots=off is considered rude.. is that generally so? Thanks for bearing with me on this question, as this is the very first time I have used wget to grab one specific file, but not knowing exactly where in the directory tree of the website the file is located. Randall
[PLUG] playing around with the wget command finally worked
At the risk of being blocked by the Skalfti website, I found that the following wget command grabs one and only one file %wget -r -A 'index.js' -e robots=off -O index.js https://vafri.is/quake/ Notice that I had to give the file a name using the -O option, and it is stored in the current working directory. I read that using the option -e robots=off is considered rude.. is that generally so? Thanks for bearing with me on this question, as this is the very first time I have used wget to grab one specific file, but not knowing exactly where in the directory tree of the website the file is located. Randall
[PLUG] Question: grabbing only 1 file using wget
Hello: I am trying to grab one specific file from a quake monitoring website using wget. The file name is "index.js" The wget command is % wget -r -l3 --no-parent -A "index.js" https://vafri.is/quake/ However the results do NOT come back with the file at all, but apparently the wget command is deflected and unable to retrieve the file. I can do a manual save of the website as an html file with an html directory which contains the "index.js" file. What am I doing wrong? Thank you for the clarification/correction and advice. Randall
Re: [PLUG] Can someone enlighten me on H.265/HEVC
Ted I am running openSuse Leap 15.4 latest and attempted to run the https://test-videos.co.uk/bigbuckbunny/mp4-h265 video Mozilla Firefox gets codec error and aborts Brave, Opera, and Chrome all open the video window, then stall out. I wonder if someone should contact the Packman people on this?? They seem to stay updated on all linux media things. - Randall
Re: [PLUG] Recovering physical memory question
Before running this command, please make sure that your system has enough available physical memory to do the transfer. I did this once, having about 11 or 12 gigs swap, and only 4 gigs avail, and suddenly realized that all physical memory was going to be swallowed. Try as I could (using htop commands) I could NOT abort the swapoff command, despite how many sig signals were sent to the command after it became live. On 8/18/22 15:38, Russell Senior wrote: If you want to recover the swap space back into RAM (assuming the RAM is available again): sudo swapoff -a sudo swapon -a ... should do the trick. On Thu, Aug 18, 2022 at 3:00 PM American Citizen wrote: Hi: I have been running a mathematical programming language on my openSuse Linux system, but have noticed that running programs in this language seem to be chewing up physical memory, but not releasing it back when the program is terminated, or killed. Once I had all 32 gigs of memory allocated and about 12 gigs of swap, leading to a severely swamped system, which I barely recovered from. Is there any command that can be run, to recover good physical memory? I know rebooting the system will recover the physical memory, but this is the last step. I suspect a memory leak in the programming language as the cause of all this. Thanks for your input. Randall
[PLUG] Recovering physical memory question
Hi: I have been running a mathematical programming language on my openSuse Linux system, but have noticed that running programs in this language seem to be chewing up physical memory, but not releasing it back when the program is terminated, or killed. Once I had all 32 gigs of memory allocated and about 12 gigs of swap, leading to a severely swamped system, which I barely recovered from. Is there any command that can be run, to recover good physical memory? I know rebooting the system will recover the physical memory, but this is the last step. I suspect a memory leak in the programming language as the cause of all this. Thanks for your input. Randall
