Enhancement: Write the bug-report.sh tool

[lcn2]

Add a make report that would run the test suite and write various info to say bug-report.txt

The info would include version numbers, out of commands such as uname -a, compiler version info, contents of limit_ioccc.sh, encourage the user to report the contents of the bug-report.txt file in a GitHub bug report, etc.

[xexyl]

Again the purpose of this make bug-report rule is to create a bug-report.$(/bin/date '+%%Y%m%d.%H%M%S').txt file (out a timestamp containing information information that might be helpful to understand why someone might be having a problem compiling and running code.

Use the output of $(/bin/date '+%%Y%m%d.%H%M%S') to put a timestamp into the filename.

So things like the following could be written to this file:

• make clobber
• uname -a [...]

I thought of a problem with uname -a: it will show the host name or even FQDN. This does not bother me but it might bother other people. So what options should be used? I propose:

uname -srvm

which works under both linux and macOS. The options in linux -oi are redundant and macOS does not have them.

Run uname multiple times ... do both uname -a and uname -srvm.

But the problem is that it will show host name which some people might not like? And why run it twice? Well anyway that can be decided in the coming days. I am starting to sit up so that I will be forced to get ready to sleep. Take good care and I will reply more tomorrow.

The bug report log is only generated. People are free to edit it as they like, or even not sent it.

Collect information into the bug report. Tell the user that they can read the bug report in the file that was created.

No need to handle the case where someone might be offended by what is produced in the bug report file.

We might also tell them that if they want to remove their hostname they can do so. But the question is do we really need the -a option? I mean if we specify everything else it won't be needed, right? But let's say we do add it (since you seem to think it's important): why do we need to run it another time with the other options that -a actually implies?

Hope you're having a nice sleep. I'm going to take a look and see if I am missing replying to anything and if not I'll possibly take a break though I can't figure out what as I can't sleep or even rest but not really feeling up to doing anything either.

[xexyl]

BTW: The two comments noted below are not urgent

Just so you know: I don't think there's anything to reply to in comment https://github.com/ioccc-src/mkiocccentry/issues/248#issuecomment-1279716568 and comment https://github.com/ioccc-src/mkiocccentry/issues/248#issuecomment-1279716992 at least any time soon. It was mostly me going through the thoughts. There's only one thing that I'm not sure of but if it's not enough (when I get round to adding it) we will certainly figure it out.

I'm going to shut the laptop off for a bit now and return to it later on. Maybe I can do more here. We'll see.

[xexyl]

As of some hours ago with commit f7e24a436f1fbbb179c8d9dba64799b41d07a696 I have added some new checks that were not thought of before that I think will be great to have. It's also been made modular by way of a function. The checks added in particular:

• Prints out the script version.
• Runs bash --version.
• Runs ./run_bison.sh -v 1.
• Runs ./run_flex.sh -v 1.
• Checks for a readable makefile.local and cats it to the log if so. It will report an unreadable makefile.local and it will also report if there's makefile.local. This is important because this file could override important steps.
• Attempt to cat limit_ioccc.sh as this might have some useful information as well. This is not an error if they don't have it though perhaps it should be since make all will actually generate it (or it should). It's not an error because most tools don't need it. It only just occurred to me that some do use it so maybe it should be an error. Anyway for now it's not.
• Tries to check for code changes via git --no-pager diff. This is also not an error if it fails as it might be that it's because of no git installed or they're outside the repo. Also git returns 0 for differences and no differences so there's nothing really to check. What matters is the output of the command. If it returns an error because git does not exist or it's not in the repo we won't need to know it. Finally since we'll have output anyway there doesn't necessarily even need to be an exit code change if it's not installed or they're out of the repo.

I'm curious what you think about these and if you have other ideas. I don't think I'll do anything else here today except maybe reply to comments. The other day I had an idea for the txzchk test script but I'll say that in that thread instead. After that I'll be doing something else. I hope you had a nice sleep and have a great day!

[lcn2]

How ironic that a commit I accidentally made yesterday removed the execute bit from hostchk.sh when we're talking about executable scripts!

😄

[lcn2]

Will do these checks but do we need the full output of the help mode? Or will version be enough? I'm just thinking out loud here: ...

Perhaps output of -V is good enough. We will need to be more mindful to update the VERSION although there is NO need to automate such version updates. All we want to do is to get an idea which version of a tool someone might be using when they file a bug report.

[xexyl]

Will do these checks but do we need the full output of the help mode? Or will version be enough? I'm just thinking out loud here: ...

Perhaps output of -V is good enough. We will need to be more mindful to update the VERSION although there is NO need to automate such version updates. All we want to do is to get an idea which version of a tool someone might be using when they file a bug report.

Yes that makes sense. I'll do that but probably not until tomorrow. I hope that's okay.

[lcn2]

Again the purpose of this make bug-report rule is to create a bug-report.$(/bin/date '+%%Y%m%d.%H%M%S').txt file (out a timestamp containing information information that might be helpful to understand why someone might be having a problem compiling and running code.

Use the output of $(/bin/date '+%%Y%m%d.%H%M%S') to put a timestamp into the filename.

So things like the following could be written to this file:

• make clobber
• uname -a [...]

I thought of a problem with uname -a: it will show the host name or even FQDN. This does not bother me but it might bother other people. So what options should be used? I propose:

uname -srvm

which works under both linux and macOS. The options in linux -oi are redundant and macOS does not have them.

Run uname multiple times ... do both uname -a and uname -srvm.

But the problem is that it will show host name which some people might not like? And why run it twice? Well anyway that can be decided in the coming days. I am starting to sit up so that I will be forced to get ready to sleep. Take good care and I will reply more tomorrow.

The bug report log is only generated. People are free to edit it as they like, or even not sent it. Collect information into the bug report. Tell the user that they can read the bug report in the file that was created.

No need to handle the case where someone might be offended by what is produced in the bug report file.

We might also tell them that if they want to remove their hostname they can do so. But the question is do we really need the -a option? I mean if we specify everything else it won't be needed, right? But let's say we do add it (since you seem to think it's important): why do we need to run it another time with the other options that -a actually implies?

Hope you're having a nice sleep. I'm going to take a look and see if I am missing replying to anything and if not I'll possibly take a break though I can't figure out what as I can't sleep or even rest but not really feeling up to doing anything either.

We suggest a more positive approach, such as putting a notice at the top of the log file, informing them that:

This file contains various information about their compile environment including things such as hostname, operating system information, paths and versions of various tools.  Although not encouraged, users are free to edit this file if they feel so inclined.  This information is added to this file in case it proves useful in debugging a problem, and therefore we kindly request that you provide it to us when you report a problem with this code.

[xexyl]

Again the purpose of this make bug-report rule is to create a bug-report.$(/bin/date '+%%Y%m%d.%H%M%S').txt file (out a timestamp containing information information that might be helpful to understand why someone might be having a problem compiling and running code.

Use the output of $(/bin/date '+%%Y%m%d.%H%M%S') to put a timestamp into the filename.

So things like the following could be written to this file:

• make clobber
• uname -a [...]

I thought of a problem with uname -a: it will show the host name or even FQDN. This does not bother me but it might bother other people. So what options should be used? I propose:

uname -srvm

which works under both linux and macOS. The options in linux -oi are redundant and macOS does not have them.

Run uname multiple times ... do both uname -a and uname -srvm.

But the problem is that it will show host name which some people might not like? And why run it twice? Well anyway that can be decided in the coming days. I am starting to sit up so that I will be forced to get ready to sleep. Take good care and I will reply more tomorrow.

The bug report log is only generated. People are free to edit it as they like, or even not sent it. Collect information into the bug report. Tell the user that they can read the bug report in the file that was created.

No need to handle the case where someone might be offended by what is produced in the bug report file.

We might also tell them that if they want to remove their hostname they can do so. But the question is do we really need the -a option? I mean if we specify everything else it won't be needed, right? But let's say we do add it (since you seem to think it's important): why do we need to run it another time with the other options that -a actually implies? Hope you're having a nice sleep. I'm going to take a look and see if I am missing replying to anything and if not I'll possibly take a break though I can't figure out what as I can't sleep or even rest but not really feeling up to doing anything either.

We suggest a more positive approach, such as putting a notice at the top of the log file, informing them that:

This file contains various information about their compile environment including things such as hostname, operating system information, paths and versions of various tools.  Although not encouraged, users are free to edit this file if they feel so inclined.  This information is added to this file in case it proves useful in debugging a problem, and therefore we kindly request that you provide it to us when you report a problem with this code.

That's a good idea. I can do that in a future update as well.

... it might be good to have it at the end though and not in the log. Show it when telling them where it was saved to etc.

[lcn2]

As of some hours ago with commit f7e24a4 I have added some new checks that were not thought of before that I think will be great to have. It's also been made modular by way of a function. The checks added in particular:

• Prints out the script version.
• Runs bash --version.
• Runs ./run_bison.sh -v 1.
• Runs ./run_flex.sh -v 1.
• Checks for a readable makefile.local and cats it to the log if so. It will report an unreadable makefile.local and it will also report if there's makefile.local. This is important because this file could override important steps.
• Attempt to cat limit_ioccc.sh as this might have some useful information as well. This is not an error if they don't have it though perhaps it should be since make all will actually generate it (or it should). It's not an error because most tools don't need it. It only just occurred to me that some do use it so maybe it should be an error. Anyway for now it's not.
• Tries to check for code changes via git --no-pager diff. This is also not an error if it fails as it might be that it's because of no git installed or they're outside the repo. Also git returns 0 for differences and no differences so there's nothing really to check. What matters is the output of the command. If it returns an error because git does not exist or it's not in the repo we won't need to know it. Finally since we'll have output anyway there doesn't necessarily even need to be an exit code change if it's not installed or they're out of the repo.

I'm curious what you think about these and if you have other ideas. I don't think I'll do anything else here today except maybe reply to comments. The other day I had an idea for the txzchk test script but I'll say that in that thread instead. After that I'll be doing something else. I hope you had a nice sleep and have a great day!

Interesting ideas.

The file should be formatted in a way to make it easy for tools, such as grep(1) and friends to find information. The log file will contain lots of information, most of which may not be useful in debugging problem.

It would be nice to mark with a string such as ISSUE: when a problem is found (such as when foo -V fails to produce output, or the C compiler is missing, etc. I.e., think about, when a bug report file is received, doing something like:

grep ISSUE: foo.txt

to get a quick summary of potential problems.

We image that the big report file will contain sections. It would be nice if the sections were easily viewed, via some marker such as:

#=-=# Start of section 4 - tool version numbers #=-=#

with whitespace that looks both pleasing and easy to find when scanning.

[lcn2]

Again the purpose of this make bug-report rule is to create a bug-report.$(/bin/date '+%%Y%m%d.%H%M%S').txt file (out a timestamp containing information information that might be helpful to understand why someone might be having a problem compiling and running code.

Use the output of $(/bin/date '+%%Y%m%d.%H%M%S') to put a timestamp into the filename.

So things like the following could be written to this file:

• make clobber
• uname -a [...]

I thought of a problem with uname -a: it will show the host name or even FQDN. This does not bother me but it might bother other people. So what options should be used? I propose:

uname -srvm

which works under both linux and macOS. The options in linux -oi are redundant and macOS does not have them.

Run uname multiple times ... do both uname -a and uname -srvm.

But the problem is that it will show host name which some people might not like? And why run it twice? Well anyway that can be decided in the coming days. I am starting to sit up so that I will be forced to get ready to sleep. Take good care and I will reply more tomorrow.

The bug report log is only generated. People are free to edit it as they like, or even not sent it. Collect information into the bug report. Tell the user that they can read the bug report in the file that was created.

No need to handle the case where someone might be offended by what is produced in the bug report file.

We might also tell them that if they want to remove their hostname they can do so. But the question is do we really need the -a option? I mean if we specify everything else it won't be needed, right? But let's say we do add it (since you seem to think it's important): why do we need to run it another time with the other options that -a actually implies? Hope you're having a nice sleep. I'm going to take a look and see if I am missing replying to anything and if not I'll possibly take a break though I can't figure out what as I can't sleep or even rest but not really feeling up to doing anything either.

We suggest a more positive approach, such as putting a notice at the top of the log file, informing them that:

This file contains various information about their compile environment including things such as hostname, operating system information, paths and versions of various tools.  Although not encouraged, users are free to edit this file if they feel so inclined.  This information is added to this file in case it proves useful in debugging a problem, and therefore we kindly request that you provide it to us when you report a problem with this code.

That's a good idea. I can do that in a future update as well.

... it might be good to have it at the end though and not in the log. Show it when telling them where it was saved to etc.

The key is to positive .. don't alarm the user nor try to inform them of everything that might is in a bug report. The user can always scan it for themselves. Just be up front about that general contents and purpose in a positive way.

[xexyl]

As of some hours ago with commit f7e24a4 I have added some new checks that were not thought of before that I think will be great to have. It's also been made modular by way of a function. The checks added in particular:

• Prints out the script version.
• Runs bash --version.
• Runs ./run_bison.sh -v 1.
• Runs ./run_flex.sh -v 1.
• Checks for a readable makefile.local and cats it to the log if so. It will report an unreadable makefile.local and it will also report if there's makefile.local. This is important because this file could override important steps.
• Attempt to cat limit_ioccc.sh as this might have some useful information as well. This is not an error if they don't have it though perhaps it should be since make all will actually generate it (or it should). It's not an error because most tools don't need it. It only just occurred to me that some do use it so maybe it should be an error. Anyway for now it's not.
• Tries to check for code changes via git --no-pager diff. This is also not an error if it fails as it might be that it's because of no git installed or they're outside the repo. Also git returns 0 for differences and no differences so there's nothing really to check. What matters is the output of the command. If it returns an error because git does not exist or it's not in the repo we won't need to know it. Finally since we'll have output anyway there doesn't necessarily even need to be an exit code change if it's not installed or they're out of the repo.

I'm curious what you think about these and if you have other ideas. I don't think I'll do anything else here today except maybe reply to comments. The other day I had an idea for the txzchk test script but I'll say that in that thread instead. After that I'll be doing something else. I hope you had a nice sleep and have a great day!

Interesting ideas.

The file should be formatted in a way to make it easy for tools, such as grep(1) and friends to find information. The log file will contain lots of information, most of which may not be useful in debugging problem.

Agreed. I've been working at that which you'll see in the log. It needs a bit of work yet.

It would be nice to mark with a string such as ISSUE: when a problem is found (such as when foo -V fails to produce output, or the C compiler is missing, etc. I.e., think about, when a bug report file is received, doing something like:

grep ISSUE: foo.txt

to get a quick summary of potential problems.

Of course.

We image that the big report file will contain sections. It would be nice if the sections were easily viewed, via some marker such as:

#=-=# Start of section 4 - tool version numbers #=-=#

with whitespace that looks both pleasing and easy to find when scanning.

Sections is a great idea. Right now one can use grep to find out what is being tested but more needs to be done here. Anyway try:

grep '^##' ...

But more can be done and more will be done. As noted it's definitely a work in progress.

[xexyl]

Again the purpose of this make bug-report rule is to create a bug-report.$(/bin/date '+%%Y%m%d.%H%M%S').txt file (out a timestamp containing information information that might be helpful to understand why someone might be having a problem compiling and running code.

Use the output of $(/bin/date '+%%Y%m%d.%H%M%S') to put a timestamp into the filename.

So things like the following could be written to this file:

• make clobber
• uname -a [...]

I thought of a problem with uname -a: it will show the host name or even FQDN. This does not bother me but it might bother other people. So what options should be used? I propose:

uname -srvm

which works under both linux and macOS. The options in linux -oi are redundant and macOS does not have them.

Run uname multiple times ... do both uname -a and uname -srvm.

But the problem is that it will show host name which some people might not like? And why run it twice? Well anyway that can be decided in the coming days. I am starting to sit up so that I will be forced to get ready to sleep. Take good care and I will reply more tomorrow.

The bug report log is only generated. People are free to edit it as they like, or even not sent it. Collect information into the bug report. Tell the user that they can read the bug report in the file that was created.

No need to handle the case where someone might be offended by what is produced in the bug report file.

We might also tell them that if they want to remove their hostname they can do so. But the question is do we really need the -a option? I mean if we specify everything else it won't be needed, right? But let's say we do add it (since you seem to think it's important): why do we need to run it another time with the other options that -a actually implies? Hope you're having a nice sleep. I'm going to take a look and see if I am missing replying to anything and if not I'll possibly take a break though I can't figure out what as I can't sleep or even rest but not really feeling up to doing anything either.

We suggest a more positive approach, such as putting a notice at the top of the log file, informing them that:

This file contains various information about their compile environment including things such as hostname, operating system information, paths and versions of various tools.  Although not encouraged, users are free to edit this file if they feel so inclined.  This information is added to this file in case it proves useful in debugging a problem, and therefore we kindly request that you provide it to us when you report a problem with this code.

That's a good idea. I can do that in a future update as well. ... it might be good to have it at the end though and not in the log. Show it when telling them where it was saved to etc.

The key is to positive .. don't alarm the user nor try to inform them of everything that might is in a bug report. The user can always scan it for themselves. Just be up front about that general contents and purpose in a positive way.

Of course. I got it. I was just saying that it would be better to have it at the end since they'll be more likely to see it.

[lcn2]

Remember that the purpose is, when someone thinks they have a problem with the repo code and go though the effort to report it as an issue, that we collect enough information up front so as to minimize the need for a back and forth "try this and let is know what it does ... here is what it does .. well try this other thing ... don't understand ... we mean try this command .. oh it did this ..." sort of thing.

[xexyl]

Remember that the purpose is, when someone thinks they have a problem with the repo code and go though the effort to report it as an issue, that we collect enough information up front so as to minimize the need for a back and forth "try this and let is know what it does ... here is what it does .. well try this other thing ... don't understand ... we mean try this command .. oh it did this ..." sort of thing.

Yes. Which is why I think trying to determine if they have modified the code in any form is also a good idea (as the commit does). That as well as seeing if there are any Makefile overrides as well as some others I thought of when I was showering this morning. I'm certainly open to additional checks being suggested as well though. What you gave above is great too.

That being said I will be leaving for the day soon - well at least at the laptop and won't be able to reply for a while.

[xexyl]

Oh I also updated the GitHub template for bug reports. I think it might be good to have an entire section in the report but I don't really know much about GitHub templates. But anyway see 86b4a0217de0a6f4b6b8f17aac0e39db7bb22f07. Please feel free to improve it.

[lcn2]

Oh I also updated the GitHub template for bug reports. I think it might be good to have an entire section in the report but I don't really know much about GitHub templates. But anyway see 86b4a02. Please feel free to improve it.

In order to close this use, a complete review and updates to the GitHub template for bug reports is needed.

Such a GitHub template for bug reports will need to make is clear that we really do want them to upload a bug report file. We can humorously ask them near the bottom, if they remembered to upload a bug report file. ;-)

[xexyl]

Oh I also updated the GitHub template for bug reports. I think it might be good to have an entire section in the report but I don't really know much about GitHub templates. But anyway see 86b4a02. Please feel free to improve it.

In order to close this use, a complete review and updates to the GitHub template for bug reports is needed.

Such a GitHub template for bug reports will need to make is clear that we really do want them to upload a bug report file. We can humorously ask them near the bottom, if they remembered to upload a bug report file. ;-)

All of that sounds good to me. Well we can discuss it more later. Or not. If you have an idea on what it should say go for it. Anyway I'll be writing more tomorrow. Good day and night!

[lcn2]

Oh I also updated the GitHub template for bug reports. I think it might be good to have an entire section in the report but I don't really know much about GitHub templates. But anyway see 86b4a02. Please feel free to improve it.

In order to close this use, a complete review and updates to the GitHub template for bug reports is needed. Such a GitHub template for bug reports will need to make is clear that we really do want them to upload a bug report file. We can humorously ask them near the bottom, if they remembered to upload a bug report file. ;-)

All of that sounds good to me. Well we can discuss it more later. Or not. If you have an idea on what it should say go for it. Anyway I'll be writing more tomorrow. Good day and night!

Best wishes on a good sleep!

[xexyl]

Oh I also updated the GitHub template for bug reports. I think it might be good to have an entire section in the report but I don't really know much about GitHub templates. But anyway see 86b4a02. Please feel free to improve it.

In order to close this use, a complete review and updates to the GitHub template for bug reports is needed. Such a GitHub template for bug reports will need to make is clear that we really do want them to upload a bug report file. We can humorously ask them near the bottom, if they remembered to upload a bug report file. ;-)

All of that sounds good to me. Well we can discuss it more later. Or not. If you have an idea on what it should say go for it. Anyway I'll be writing more tomorrow. Good day and night!

Best wishes on a good sleep!

Thank you very much my friend! I wish you a great night as well!

I will be getting a snack soon and then getting ready to sleep. I guess you will react to my other messages about ideas (if you have any suggestions beyond what you already gave earlier on today about the bug report script) later on but hopefully I can at least add some of the things you suggested.

If you have any suggestions on a different and better way to check that tar supports -J for txzchk_test.sh I am definitely open to it! (Sorry if that’s not this thread - it’s harder to see on the phone and I didn’t actually look at what thread this is .. just clicked on the link in the email).

Hope you have a great sleep! Will be going now. Good night my friend!

Edit

I see that it’s not the txzchk thread after posting it but to save me the effort trying to write the same thing there again I will keep it here. Good night!

[lcn2]

Oh I also updated the GitHub template for bug reports. I think it might be good to have an entire section in the report but I don't really know much about GitHub templates. But anyway see 86b4a02. Please feel free to improve it.

In order to close this use, a complete review and updates to the GitHub template for bug reports is needed.

Such a GitHub template for bug reports will need to make is clear that we really do want them to upload a bug report file. We can humorously ask them near the bottom, if they remembered to upload a bug report file. ;-)

All of that sounds good to me. Well we can discuss it more later. Or not. If you have an idea on what it should say go for it. Anyway I'll be writing more tomorrow. Good day and night!

Best wishes on a good sleep!

Thank you very much my friend! I wish you a great night as well!

I will be getting a snack soon and then getting ready to sleep. I guess you will react to my other messages about ideas (if you have any suggestions beyond what you already gave earlier on today about the bug report script) later on but hopefully I can at least add some of the things you suggested.

If you have any suggestions on a different and better way to check that tar supports -J for txzchk_test.sh I am definitely open to it! (Sorry if that’s not this thread - it’s harder to see on the phone and I didn’t actually look at what thread this is .. just clicked on the link in the email).

Hope you have a great sleep! Will be going now. Good night my friend!

Edit

I see that it’s not the txzchk thread after posting it but to save me the effort trying to write the same thing there again I will keep it here. Good night!

Perhaps the bug-report script could attempt to create a temporary tarball (using mktemp(1) and trap ... 0 1 2 3 15 plus an explicit rm -f after the test to remove it) from the shell bug-report.sh file using -J? If the process successfully creates a tarball and the tar does an exits 0, then all is OK.

[xexyl]

Oh I also updated the GitHub template for bug reports. I think it might be good to have an entire section in the report but I don't really know much about GitHub templates. But anyway see 86b4a02. Please feel free to improve it.

In order to close this use, a complete review and updates to the GitHub template for bug reports is needed.

Such a GitHub template for bug reports will need to make is clear that we really do want them to upload a bug report file. We can humorously ask them near the bottom, if they remembered to upload a bug report file. ;-)

All of that sounds good to me. Well we can discuss it more later. Or not. If you have an idea on what it should say go for it. Anyway I'll be writing more tomorrow. Good day and night!

Best wishes on a good sleep!

Thank you very much my friend! I wish you a great night as well! I will be getting a snack soon and then getting ready to sleep. I guess you will react to my other messages about ideas (if you have any suggestions beyond what you already gave earlier on today about the bug report script) later on but hopefully I can at least add some of the things you suggested. If you have any suggestions on a different and better way to check that tar supports -J for txzchk_test.sh I am definitely open to it! (Sorry if that’s not this thread - it’s harder to see on the phone and I didn’t actually look at what thread this is .. just clicked on the link in the email). Hope you have a great sleep! Will be going now. Good night my friend!

Edit

I see that it’s not the txzchk thread after posting it but to save me the effort trying to write the same thing there again I will keep it here. Good night!

Perhaps the bug-report script could attempt to create a temporary tarball (using mktemp(1) and trap ... 0 1 2 3 15 plus an explicit rm -f after the test to remove it) from the shell bug-report.sh file using -J? If the process successfully creates a tarball and the tar does an exits 0, then all is OK.

Well that script already does via hostchk.sh. The issue is whether the txzchk_test.sh script also should. It was suggested that it should so I will go about it that way. It need only do it once.

I also think it might benefit from a summary like some other scripts do (for example the bug_report.sh one).

I am going to boot the laptop soon and hopefully I can work on the repo. I am not happy that I am awake now but I can’t sleep and I suppose I got enough hours though it was rough sleep.

Hope you’re having a good sleep my friend!

… and at least two hours have passed and I still haven’t booted up the laptop … I just had a shower and now I am trying to determine if my body will let me rest. I think the answer is probably no. If that’s the case I probably will boot the laptop. But this is not certain either. I feel like today is going to be a very slow day. However I still hope I can get some things done here.

I can already tell you I won’t be able to rest so I am going to sit up and hopefully get some things done.

Btw here’s something I realised about sitting. Thought if this a while back and I think it will make you laugh or at least you’ll find it amusing: in order to sit up you actually have to sit down!

[lcn2]

in order to sit up you actually have to sit down!

😁

[xexyl]

in order to sit up you actually have to sit down!

😁

Glad you got a laugh out of that! I hope you're having a great day.

[xexyl]

So some things occurred to me. You had mentioned to query bison and flex for version information. But there are some some things to consider with this.

First of all with the -v 1 flag of run_bison.sh and run_flex.sh is this actually necessary?

But also if we do do say which on the two tools and then -V it might end up being a different version than the one that the two scripts find. Is this a problem? Do we need to do this? Any other thoughts about this?

[lcn2]

So some things occurred to me. You had mentioned to query bison and flex for version information. But there are some some things to consider with this.

First of all with the -v 1 flag of run_bison.sh and run_flex.sh is this actually necessary?

But also if we do do say which on the two tools and then -V it might end up being a different version than the one that the two scripts find. Is this a problem? Do we need to do this? Any other thoughts about this?

If the versions are produced indirectly via the scripts, that's OK.

[xexyl]

So some things occurred to me. You had mentioned to query bison and flex for version information. But there are some some things to consider with this. First of all with the -v 1 flag of run_bison.sh and run_flex.sh is this actually necessary? But also if we do do say which on the two tools and then -V it might end up being a different version than the one that the two scripts find. Is this a problem? Do we need to do this? Any other thoughts about this?

If the versions are produced indirectly via the scripts, that's OK.

You know I'm not sure if they are. I just know that they show whether it's a version that will work. Is that okay too?

[lcn2]

So some things occurred to me. You had mentioned to query bison and flex for version information. But there are some some things to consider with this. First of all with the -v 1 flag of run_bison.sh and run_flex.sh is this actually necessary? But also if we do do say which on the two tools and then -V it might end up being a different version than the one that the two scripts find. Is this a problem? Do we need to do this? Any other thoughts about this?

If the versions are produced indirectly via the scripts, that's OK.

You know I'm not sure if they are. I just know that they show whether it's a version that will work. Is that okay too?

We recommend using a more verbose level such as:

./run_bison.sh -v 7
./run_flex.sh -v 7

as this will provide better information for the bug report.

[xexyl]

So some things occurred to me. You had mentioned to query bison and flex for version information. But there are some some things to consider with this. First of all with the -v 1 flag of run_bison.sh and run_flex.sh is this actually necessary? But also if we do do say which on the two tools and then -V it might end up being a different version than the one that the two scripts find. Is this a problem? Do we need to do this? Any other thoughts about this?

If the versions are produced indirectly via the scripts, that's OK.

You know I'm not sure if they are. I just know that they show whether it's a version that will work. Is that okay too?

We recommend using a more verbose level such as:

./run_bison.sh -v 7
./run_flex.sh -v 7

as this will provide better information for the bug report.

Made the change just now and will commit it tomorrow I expect.

[xexyl]

I don't think I'll be doing anything today: last night was very difficult and I'm very tired and just don't feel up to much. Thus I am taking a break today I think. But that being said I do have things to discuss with this issue.

Should sed --version and awk --version be used? On the one hand no tool really requires any of these except for run_flex.sh and run_bison.sh and in particular awk. But if that function in the script fails a backup file can be used so is it a problem?

On the other hand if we have awk and sed we can have a fully correct limit_ioccc.sh file which is very useful. I don't really know what would happen if one or both tools are missing actually. I could temporarily change the path but I'd rather not worry about it: it is what it is.

But something else occurred to me and that is that the grep -o option is not POSIX compliant. It seems to be in different implementations like macOS (I guess other BSD unices too) and definitely there in linux. It's used in hostchk.sh to determine the include files needed. I'm not sure there's a way past this one. It might be with even more code but is it worth it?

This goes back to the question at the beginning of this comment: what about awk and sed version? Certainly having this information is useful. However should it be considered an issue or just warn if either return an error (probably from not existing)?

And what about grep? Should I also do grep -V? If so should it be an error if it does not exist (unlikely though that might be) or should I just warn? In the case of sed no script needs it that's not a test script; in the case of awk with the exception of run_usage.sh (which is far from perfect and but designed to help me with the man pages at least until I add more correct/standard format for SYNOPSIS) only the two scripts I mentioned above - the run bison and run flex ones - need awk but if these fail the scripts will use backup files so it shouldn't be a fatal problem.

As for grep though: hostchk.sh needs the non POSIX -o option and that's also run by default so what happens if one is to not have that option available and tries using this repo? Should I maybe look at doing this a different way? If so do you have any suggestions? Also: ioccc_test.sh needs grep though it should not have a problem with any options. The rest of the scripts using it are for us and in the case of the reset timestamp one only you and Leo. Some scripts use grep -v to filter out 'Nothing to be done' when using make all first.

What do you think? And with that said I hope I can do more tomorrow though I do have a zoom meeting in the morning. Good day!

[lcn2]

Should sed --version and awk --version be used? On the one hand no tool really requires any of these except for run_flex.sh and run_bison.sh and in particular awk. But if that function in the script fails a backup file can be used so is it a problem?

Gathering such information (existence, path (if it exits), version (if exits and possible) on standard tools that are used in this repo:

$SHELL (their default shell)
awk
basename
bash (needed because we have explicit use of bash)
cat
cc
cmp
cp
cut
date
echo
find
getopts
grep
make
mktemp
mv
printf
rm
sed
tar
tee
touch
tr
true
yes

Plus the optional tools (where the lack of these tools is NOT an issue for compiling the repo):

bison
checknr
ctags
flex
gdate
install
man
man2html
picky
rpl
seqcexit
shellcheck

should be noted in the tool.

We may have missed something, but those tools come to mind.

UPDATE 0

Added a few tools that came to mind after posting the comment. :)

UPDATE 1

More updates .. sorted list

[xexyl]

Should sed --version and awk --version be used? On the one hand no tool really requires any of these except for run_flex.sh and run_bison.sh and in particular awk. But if that function in the script fails a backup file can be used so is it a problem?

Gathering such information (existence, path (if it exits), version (if exits and possible) on standard tools that are used in this repo:

awk
basename
cat
cut
cc
cp
grep
make
man
mktemp
mv
rm
sed
$SHELL (their default shell)
bash (needed because we have explicit use of bash)
tee
tr
true

Plus the optional tools (where the lack of these tools is NOT an issue for compiling the repo):

ctags
install
man2html
picky
seqcexit
shellcheck
checknr
rpl

should be noted in the tool.

We may have missed something, but those tools come to mind.

GREAT list! Thank you. I'll look at that next time. What about my question when it comes to the option of -o for grep? I guess it'll indirectly be a problem if they don't have it and if so it'll be noticeable. Hopefully we don't have that problem though. If necessary we can probably fetch the value with sed as well but that might be overkill.

EDIT: I already checked for bash version of course. Same with make and maybe a few others.

[xexyl]

Good morning! I have run into a slight problem with some of the above version checks. We can certainly do which on them but under BSD / macOS there is no version option. For instance:

$ /usr/bin/sed --version
/usr/bin/sed: illegal option -- -
usage: sed script [-Ealnru] [-i extension] [file ...]
    sed [-Ealnu] [-i extension] [-e script] ... [-f script_file] ... [file ...]

Now under macOS as it happens I have installed GNU sed and use an alias for it. But for the script we use what will be found from which which (...) might not be the other versions. In fact with MacPorts it installs it to gsed which I just alias as sed. But in the script it won't deal with aliases and I don't think it should either as possible options given could conflict with what we'er after.

The same problem can be found for basename. Now in BSD there's a handy utility:

$ sw_vers 
ProductName:    macOS
ProductVersion: 12.6
BuildVersion:   21G115

and I could do something like:

$ which sw_vers 2>/dev/null && sw_vers

but obviously this cannot be considered an error if it fails. Since more than one command has no --version under BSD I might want to write another function that prints out the appropriate information but the problem with that is we don't want to run sw_vers more than once. So we might want to do --version but make it a warning. I did that for sed but it seem s I'll have to do that for basename as well.

There seems to be no string in the binary either for version with sed. The closest I found (and I don't know what it means but I can take a guess .. but not sure if it'll apply to basename or others):

$ strings /usr/bin/sed|head -n1
@(#)PROGRAM:sed  PROJECT:text_cmds-138.100.3

which very possibly is the version. But even so in linux you won't have that so how to identify it? Do we try checking if the system is BSD (maybe via sw_vers existing) and if so run specific checks? If it's linux also run linux specific checks?

Sorry if this is too many questions in one comment. I'm very tired and I'll be taking a break after this .. only just occurred to me I wrote a lot in this comment. If you'd like I will break this comment into several and then delete this comment. However I will try giving a summary:

Summary

In BSD some commands do not have --version. Amongst them: cut, basename, sed. How do we handle this? BSD has sw_vers and we can try using that but is it enough? Do we need a check for linux versus BSD and run specific checks?

I don't really have an answer to these questions and unfortunately I cannot add the checks to the script until I do have an answer.

UPDATE 0

See the below comment https://github.com/ioccc-src/mkiocccentry/issues/248#issuecomment-1288843989 for how to determine versions under BSD of those tools. There still are questions to be answered in order for me to continue as far as how to get the information but at least we have a way to get the version of the tools.

[xexyl]

Re the above comment about versions I have an update. The strings command can be used for finding the version! Indeed according to https://opensource.apple.com/releases/ if you expand say macOS 12.5 you will find the text_cmds there and it is a version. But what about the others?

$ strings /usr/bin/cut|head -n1
@(#)PROGRAM:cut  PROJECT:text_cmds-138.100.3
$ strings /usr/bin/basename | head -n 1
@(#)PROGRAM:basename  PROJECT:shell_cmds-240.100.15

So can you think of a good way to determine if a system is BSD and then do it this way instead of using --version? (Hopefully the above will work under other BSD Unices .. I think I saw that it does but I could be wrong.)

Problem is the GNU versions do not have such strings so it's impossible to do it for all systems. However in the case of BSD we could on the commands that don't have --version do instead:

strings .. | grep PROGRAM

which would give us the version of the tool. It's just that it's not portable any more than the linux --version is.

What do you think should be done?

UPDATE 0

Note that some commands do have a --version under BSD. For example:

$ awk --version
awk version 20200816

and

$  grep --version
grep (BSD grep, GNU compatible) 2.6.0-FreeBSD

Problem is that because of this the output is also unportable so we can't necessarily do what we do to get the version of bison and flex. For whatever reason those tools (fortunately enough) have a -V option under BSD also.

What do you think about all of this ? Once we have an idea I can add these checks in.

[xexyl]

UPDATE 0

Added a few tools that came to mind after posting the comment. :)

UPDATE 1

More updates .. sorted list

Good ideas. I actually was going to go through the list of tools in the Makefile. But before I even got there - before I even turned the laptop on - I thought of another one to do and I've added it. Unfortunately I won't be committing it likely until the other issue (above on versions) is resolved as I have some thoughts in the file and I don't feel like removing them outright.

Anyway what I thought of I think will be VERY useful:

cpp -dM /dev/null

I have been awake since stupid o'clock and more so than usual so I doubt I'll get anything done today before my zoom meeting. Since macOS Ventura will be released today I'll also be doing that so I doubt for that reason I'll get anything else done as well. Hopefully tomorrow is a better day in that regard.

BTW: if you do edit a list like that for future reference please note it in a new comment so I'm aware of it. I only saw it because I wanted to reply to it to note the new idea I had about getting predefined macros.

And with that I'm shutting the laptop off. I know I won't sleep but I'm so tired and I have to try and rest.

[xexyl]

Plus the optional tools (where the lack of these tools is NOT an issue for compiling the repo):

bison
checknr
ctags
flex
gdate
install
man
man2html
picky
rpl
seqcexit
shellcheck

But as far as gdate that I guess is a GNU version of it which we don't necessarily use. However see the above comments about versions and this failing possibly. How to address this issue? Should version commands not be an issue at all? Maybe get them but don't fail? But then for some we really do need to know the versions.

And now I really am going for now.

[xexyl]

I just wrote the comments in the script - still definitely not to be committed but maybe this will give you some ideas I've had that might be good or make you think of something else. In any event I don't think i'll be doing anything today .. too tired :(

# sed --version | head -n 1: get sed version
# NOTE: this will likely fail in some BSD Unices including macOS as these do not
# have a --version option and no other way to get version via the command
# itself. However we can try doing:
#
#       strings /usr/bin/sed | head -n 1
#
# which seems to have a version string of a kind. Under macOS this gives:
#
#       $ strings /usr/bin/sed | head -n 1
#       @(#)PROGRAM:sed  PROJECT:text_cmds-138.100.3
#
# It seems though that this formatting is not consistent across BSDs. For
# example under FreeBSD it appears to be:
#
#       #ifndef lint
#       static const char sccsid[] = "@(#)main.c        8.2 (Berkeley) 1/3/94";
#       #endif
#
# which would suggest that it probably would be:
#
#       @(#)main.c        8.2 (Berkeley) 1/3/94
#
# but unfortunately it's not the first string in the source code for sed in
# FreeBSD.
#
# These Unices have the command sw_vers which might help but this will fail on
# linux. It might be worth checking with something like:
#
#       which sw_vers 2>/dev/null && sw_vers
#
# but this will require a bit more work to get the formatting right if it's
# worth adding.
#
# So how to go about it? We could try running first sed --version and if that
# fails we could try extracting the path of sed by `which' and then use strings
# on that path. But this appears that it might not be enough all the time.

[xexyl]

Another update on the version strings. At a quick check it seems like strings might not always work either. I know I am not duplicating an actual installed system but if one compiles the FreeBSD cut.c and runs strings on a.out:

$ strings a.out 
b:c:d:f:snw
bad delimiter
stdin
[-bcf] list: illegal list value
[-bcf] list: values may not include zero
realloc
malloc
usage: cut -b list [-n] [file ...]
       cut -c list [file ...]
       cut -f list [-s] [-w | -d delim] [file ...]

and this is despite the fact that lint is not defined so that in the code anyway the string

static const char sccsid[] = "@(#)cut.c 8.3 (Berkeley) 5/4/95";

is defined. Anyway the format for macOS and FreeBSD cut 'version' do seem to differ either way.

[lcn2]

Good morning! I have run into a slight problem with some of the above version checks. We can certainly do which on them but under BSD / macOS there is no version option. For instance:

$ /usr/bin/sed --version

/usr/bin/sed: illegal option -- -

usage: sed script [-Ealnru] [-i extension] [file ...]

  sed [-Ealnu] [-i extension] [-e script] ... [-f script_file] ... [file ...]

Now under macOS as it happens I have installed GNU sed and use an alias for it. But for the script we use what will be found from which which (...) might not be the other versions. In fact with MacPorts it installs it to gsed which I just alias as sed. But in the script it won't deal with aliases and I don't think it should either as possible options given could conflict with what we'er after.

The same problem can be found for basename. Now in BSD there's a handy utility:

$ sw_vers 

ProductName:  macOS

ProductVersion:   12.6

BuildVersion: 21G115

and I could do something like:

$ which sw_vers 2>/dev/null && sw_vers

but obviously this cannot be considered an error if it fails. Since more than one command has no --version under BSD I might want to write another function that prints out the appropriate information but the problem with that is we don't want to run sw_vers more than once. So we might want to do --version but make it a warning. I did that for sed but it seem s I'll have to do that for basename as well.

There seems to be no string in the binary either for version with sed. The closest I found (and I don't know what it means but I can take a guess .. but not sure if it'll apply to basename or others):

$ strings /usr/bin/sed|head -n1

@(#)PROGRAM:sed  PROJECT:text_cmds-138.100.3

which very possibly is the version. But even so in linux you won't have that so how to identify it? Do we try checking if the system is BSD (maybe via sw_vers existing) and if so run specific checks? If it's linux also run linux specific checks?

Sorry if this is too many questions in one comment. I'm very tired and I'll be taking a break after this .. only just occurred to me I wrote a lot in this comment. If you'd like I will break this comment into several and then delete this comment. However I will try giving a summary:

Summary

In BSD some commands do not have --version. Amongst them: cut, basename, sed. How do we handle this? BSD has sw_vers and we can try using that but is it enough? Do we need a check for linux versus BSD and run specific checks?

I don't really have an answer to these questions and unfortunately I cannot add the checks to the script until I do have an answer.

UPDATE 0

See the below comment https://github.com/ioccc-src/mkiocccentry/issues/248#issuecomment-1288843989 for how to determine versions under BSD of those tools. There still are questions to be answered in order for me to continue as far as how to get the information but at least we have a way to get the version of the tools.

You will need to try a several options in order to obtain the version string. For example, try -V, try -v, try --version, try strings, what, etc. Create a function that attempts to get the version information, looking at the exit status if version information is produced. Go thru various stages until you find something, or if nothing works, give up and note that as such.

[lcn2]

Plus the optional tools (where the lack of these tools is NOT an issue for compiling the repo):

bison

checknr

ctags

flex

gdate

install

man

man2html

picky

rpl

seqcexit

shellcheck

But as far as gdate that I guess is a GNU version of it which we don't necessarily use. However see the above comments about versions and this failing possibly. How to address this issue? Should version commands not be an issue at all? Maybe get them but don't fail? But then for some we really do need to know the versions.

And now I really am going for now.

Remember that this other list is not mandatory, so if you don't find the command, it is not a problem.

[xexyl]

Plus the optional tools (where the lack of these tools is NOT an issue for compiling the repo):

bison

checknr

ctags

flex

gdate

install

man

man2html

picky

rpl

seqcexit

shellcheck

But as far as gdate that I guess is a GNU version of it which we don't necessarily use. However see the above comments about versions and this failing possibly. How to address this issue? Should version commands not be an issue at all? Maybe get them but don't fail? But then for some we really do need to know the versions. And now I really am going for now.

Remember that this other list is not mandatory, so if you don't find the command, it is not a problem.

For some reason I didn't see an email for either of these ... must be because of the update. Anyway good thing I checked here. I was going to report what I did but it seems it might not be enough just yet.

As for this list yes these are optional. However for flex and bison I just use the scripts rather than directly trying to determine the version of each. I have a warn function which does the check but does not make it an issue if it fails. Instead it just warns it as a possible issue.

[xexyl]

UPDATE 0

See the below comment #248 (comment) for how to determine versions under BSD of those tools. There still are questions to be answered in order for me to continue as far as how to get the information but at least we have a way to get the version of the tools.

You will need to try a several options in order to obtain the version string. For example, try -V, try -v, try --version, try strings, what, etc. Create a function that attempts to get the version information, looking at the exit status if version information is produced. Go thru various stages until you find something, or if nothing works, give up and note that as such.

Okay so I have a concern for some of these ideas. First the good ones.

Obviously --version either exists or it doesn't. The what command is a good one too and maybe I need to check for it existing before using it. But on what (ha) tools should I use it? I will have to determine the path first which means using the value of which. Problem (possibly) with that is that the commands (right now) as such are called via a function that reports an error if it fails. So how do I also save the value of the last command?

Doing:

    OUTPUT=$(command ${COMMAND} 2>&1 | tee -a -- "$LOG_FILE")
    # check for errors here ...
    echo "$OUTPUT" 1>&2

will show it in the log as well as the console but it will end up on some systems quite ugly like:

## RUNNING: sed --version | head -n 1

sed: illegal option -- -
usage: sed script [-Ealnru] [-i extension] [file ...]
    sed [-Ealnu] [-i extension] [-e script] ... [-f script_file] ... [file ...]
## OUTPUT OF sed --version | head -n 1 ABOVE

## RUNNING: which basename

/usr/bin/basename
## OUTPUT OF which basename ABOVE

## RUNNING: basename --version | head -n 1

basename: illegal option -- -
usage: basename string [suffix]
       basename [-a] [-s suffix] string [...]
## OUTPUT OF basename --version | head -n 1 ABOVE

## RUNNING: which cut

/usr/bin/cut
## OUTPUT OF which cut ABOVE

## RUNNING: cut --version | head -n 1

cut: illegal option -- -
usage: cut -b list [-n] [file ...]
       cut -c list [file ...]
       cut -f list [-s] [-w | -d delim] [file ...]
## OUTPUT OF cut --version | head -n 1 ABOVE

Should versions be done separately maybe? Perhaps no run_check or its warn equivalent should be used for versions? Perhaps instead it should be a different function entirely that tries all of the above. But what should it output? I'm not sure. First of all it has to obtain the path which it can do via the way I suggested (maybe the function's first argument would be the path from the previous check but then it has to be certain that it doesn't actually fail - this makes it more complicated especially as I only have two platforms I can test, linux and macOS). But then if --version fails then what? Should it be printed? Or should it be discarded? But what if it succeeds? Do we have to run it again to get the output? That would take longer though probably minimal time. Or can you think of something else?

But then there's another issue: the other options. For some it would work and some it would not. For example with -v it sometimes requires an argument which might be a problem. For some tools that option does not exist of course. Same with -V. Using what is good but then there's another question: what order should these be tried in? Finally as for strings I can do that but how many lines should I show?

I really don't know. I was starting to work on it and I was just making the --version a warn instead of a failure but now I'm not sure about committing this. I'll be taking a break now I think but maybe I can do more later. Perhaps some of the other things I've added even if the version check is not as complete as it can be is still worth committing. I'll think on that but I'm taking a break now .. hopefully at least an hour but that's impossible to determine.

[xexyl]

As far as strings goes here's a funny problem with it for BSD make (or at least NetBSD make?):

$ strings bmake|head -n18
$NetBSD: main.c,v 1.582 2022/05/07 17:49:47 rillig Exp $
@(#) Copyright (c) 1988, 1989, 1990, 1993 The Regents of the University of California.  All rights reserved.
$NetBSD: job.c,v 1.453 2022/05/07 08:01:20 rillig Exp $
$NetBSD: arch.c,v 1.210 2022/01/15 18:34:41 rillig Exp $
!<arch>
$NetBSD: buf.c,v 1.55 2022/01/08 17:25:19 rillig Exp $
$NetBSD: compat.c,v 1.241 2022/08/17 20:10:29 rillig Exp $
SVY\_
?$NetBSD: cond.c,v 1.334 2022/04/15 09:33:20 rillig Exp $
$NetBSD: dir.c,v 1.279 2022/05/07 21:19:43 rillig Exp $
SSSSSSSSSSSSSSSS
$NetBSD: for.c,v 1.168 2022/06/12 16:09:21 rillig Exp $
$NetBSD: hash.c,v 1.72 2022/02/09 21:09:24 rillig Exp $
$NetBSD: lst.c,v 1.106 2022/02/26 11:57:21 rillig Exp $
$NetBSD: make.c,v 1.256 2022/08/17 20:10:29 rillig Exp $
$NetBSD: make_malloc.c,v 1.26 2022/01/07 08:30:04 rillig Exp $
$NetBSD: metachar.c,v 1.10 2021/06/21 18:54:41 rillig Exp $
%%%%%%

...so which one to take? And how to decide? Not all tools will even have something like that. I'm at loss. And now I really am taking a break. Shutting down laptop and will have it down for a while I expect.

[xexyl]

UPDATE 0

See the below comment #248 (comment) for how to determine versions under BSD of those tools. There still are questions to be answered in order for me to continue as far as how to get the information but at least we have a way to get the version of the tools.

You will need to try a several options in order to obtain the version string. For example, try -V, try -v, try --version, try strings, what, etc. Create a function that attempts to get the version information, looking at the exit status if version information is produced. Go thru various stages until you find something, or if nothing works, give up and note that as such.

Okay so I have a concern for some of these ideas. First the good ones.

Obviously --version either exists or it doesn't. The what command is a good one too and maybe I need to check for it existing before using it. But on what (ha) tools should I use it? I will have to determine the path first which means using the value of which. Problem (possibly) with that is that the commands (right now) as such are called via a function that reports an error if it fails. So how do I also save the value of the last command?

Doing:

    OUTPUT=$(command ${COMMAND} 2>&1 | tee -a -- "$LOG_FILE")
    # check for errors here ...
    echo "$OUTPUT" 1>&2

will show it in the log as well as the console but it will end up on some systems quite ugly like:

... strange thing is that this doesn't seem to be working now. The PIPESTATUS array is not right it seems. I could have sworn it worked earlier though. I'm at this time not sure how to go about it so I'll hold off for a commit. I think today I probably won't get much done either. I suppose I could remove the assignment to a variable for now but something will have to happen in order to get the path.

The question then becomes: is it okay if which fails to come up with a path for something? I think it could be a problem but if so how do we extract the path and at the same time be able to have it in the log file and stdout and so on ? I don't know but I'm too tired to even think about it right now. Will be doing something else instead.

[lcn2]

UPDATE 0

See the below comment #248 (comment) for how to determine versions under BSD of those tools. There still are questions to be answered in order for me to continue as far as how to get the information but at least we have a way to get the version of the tools.

You will need to try a several options in order to obtain the version string. For example, try -V, try -v, try --version, try strings, what, etc. Create a function that attempts to get the version information, looking at the exit status if version information is produced. Go thru various stages until you find something, or if nothing works, give up and note that as such.

Okay so I have a concern for some of these ideas. First the good ones.

Obviously --version either exists or it doesn't. The what command is a good one too and maybe I need to check for it existing before using it. But on what (ha) tools should I use it? I will have to determine the path first which means using the value of which. Problem (possibly) with that is that the commands (right now) as such are called via a function that reports an error if it fails. So how do I also save the value of the last command?

Doing:

    OUTPUT=$(command ${COMMAND} 2>&1 | tee -a -- "$LOG_FILE")
    # check for errors here ...
    echo "$OUTPUT" 1>&2

will show it in the log as well as the console but it will end up on some systems quite ugly like:

## RUNNING: sed --version | head -n 1

sed: illegal option -- -
usage: sed script [-Ealnru] [-i extension] [file ...]
  sed [-Ealnu] [-i extension] [-e script] ... [-f script_file] ... [file ...]
## OUTPUT OF sed --version | head -n 1 ABOVE

## RUNNING: which basename

/usr/bin/basename
## OUTPUT OF which basename ABOVE

## RUNNING: basename --version | head -n 1

basename: illegal option -- -
usage: basename string [suffix]
       basename [-a] [-s suffix] string [...]
## OUTPUT OF basename --version | head -n 1 ABOVE

## RUNNING: which cut

/usr/bin/cut
## OUTPUT OF which cut ABOVE

## RUNNING: cut --version | head -n 1

cut: illegal option -- -
usage: cut -b list [-n] [file ...]
       cut -c list [file ...]
       cut -f list [-s] [-w | -d delim] [file ...]
## OUTPUT OF cut --version | head -n 1 ABOVE

Should versions be done separately maybe? Perhaps no run_check or its warn equivalent should be used for versions? Perhaps instead it should be a different function entirely that tries all of the above. But what should it output? I'm not sure. First of all it has to obtain the path which it can do via the way I suggested (maybe the function's first argument would be the path from the previous check but then it has to be certain that it doesn't actually fail - this makes it more complicated especially as I only have two platforms I can test, linux and macOS). But then if --version fails then what? Should it be printed? Or should it be discarded? But what if it succeeds? Do we have to run it again to get the output? That would take longer though probably minimal time. Or can you think of something else?

But then there's another issue: the other options. For some it would work and some it would not. For example with -v it sometimes requires an argument which might be a problem. For some tools that option does not exist of course. Same with -V. Using what is good but then there's another question: what order should these be tried in? Finally as for strings I can do that but how many lines should I show?

I really don't know. I was starting to work on it and I was just making the --version a warn instead of a failure but now I'm not sure about committing this. I'll be taking a break now I think but maybe I can do more later. Perhaps some of the other things I've added even if the version check is not as complete as it can be is still worth committing. I'll think on that but I'm taking a break now .. hopefully at least an hour but that's impossible to determine.

Nothing wrong with trying various ways to get a version of a command (assuming it exists) in a shell function, and all else fails, report version as "unknown".

You might wish to special case various commands such as true(1) in that shell function. :-)

[lcn2]

.. in what order should these be tried in? Finally as for strings I can do that but how many lines should I show?

We don't know: something for you to figure out. :-)

Again, we suspect a shell function that tries things in some canonical order will help. Plus, as we suggested above, certain commands like true(1) don't have --version, nor -v, nor -V, nor ...

$ strings /usr/bin/true
@(#)PROGRAM:true  PROJECT:shell_cmds-278

BTW: You will need to determine what happens when you find a command is a built-in to the shell. For example on macOS under zsh:

$which true
true: shell built-in command

however:

$ whereis true
true: /usr/bin/true /usr/share/man/man1/true.1

However for macOS, under bash(1):

$ which true
/usr/bin/true

All of our scripts in this repo use:

#!/usr/bin/env bash

so the bash(1) result is probably the most important to report.

[lcn2]

You are in the "figure something out and improve as needed" end of the development pool. :-)

[xexyl]

You are in the "figure something out and improve as needed" end of the development pool. :-)

LOL.

Thank you for that! That’s a very much needed laugh!

[xexyl]

UPDATE 0

See the below comment #248 (comment) for how to determine versions under BSD of those tools. There still are questions to be answered in order for me to continue as far as how to get the information but at least we have a way to get the version of the tools.

You will need to try a several options in order to obtain the version string. For example, try -V, try -v, try --version, try strings, what, etc. Create a function that attempts to get the version information, looking at the exit status if version information is produced. Go thru various stages until you find something, or if nothing works, give up and note that as such.

Okay so I have a concern for some of these ideas. First the good ones. Obviously --version either exists or it doesn't. The what command is a good one too and maybe I need to check for it existing before using it. But on what (ha) tools should I use it? I will have to determine the path first which means using the value of which. Problem (possibly) with that is that the commands (right now) as such are called via a function that reports an error if it fails. So how do I also save the value of the last command? Doing:

    OUTPUT=$(command ${COMMAND} 2>&1 | tee -a -- "$LOG_FILE")
    # check for errors here ...
    echo "$OUTPUT" 1>&2

will show it in the log as well as the console but it will end up on some systems quite ugly like:

## RUNNING: sed --version | head -n 1

sed: illegal option -- -
usage: sed script [-Ealnru] [-i extension] [file ...]
    sed [-Ealnu] [-i extension] [-e script] ... [-f script_file] ... [file ...]
## OUTPUT OF sed --version | head -n 1 ABOVE

## RUNNING: which basename

/usr/bin/basename
## OUTPUT OF which basename ABOVE

## RUNNING: basename --version | head -n 1

basename: illegal option -- -
usage: basename string [suffix]
       basename [-a] [-s suffix] string [...]
## OUTPUT OF basename --version | head -n 1 ABOVE

## RUNNING: which cut

/usr/bin/cut
## OUTPUT OF which cut ABOVE

## RUNNING: cut --version | head -n 1

cut: illegal option -- -
usage: cut -b list [-n] [file ...]
       cut -c list [file ...]
       cut -f list [-s] [-w | -d delim] [file ...]
## OUTPUT OF cut --version | head -n 1 ABOVE

Should versions be done separately maybe? Perhaps no run_check or its warn equivalent should be used for versions? Perhaps instead it should be a different function entirely that tries all of the above. But what should it output? I'm not sure. First of all it has to obtain the path which it can do via the way I suggested (maybe the function's first argument would be the path from the previous check but then it has to be certain that it doesn't actually fail - this makes it more complicated especially as I only have two platforms I can test, linux and macOS). But then if --version fails then what? Should it be printed? Or should it be discarded? But what if it succeeds? Do we have to run it again to get the output? That would take longer though probably minimal time. Or can you think of something else? But then there's another issue: the other options. For some it would work and some it would not. For example with -v it sometimes requires an argument which might be a problem. For some tools that option does not exist of course. Same with -V. Using what is good but then there's another question: what order should these be tried in? Finally as for strings I can do that but how many lines should I show? I really don't know. I was starting to work on it and I was just making the --version a warn instead of a failure but now I'm not sure about committing this. I'll be taking a break now I think but maybe I can do more later. Perhaps some of the other things I've added even if the version check is not as complete as it can be is still worth committing. I'll think on that but I'm taking a break now .. hopefully at least an hour but that's impossible to determine.

Nothing wrong with trying various ways to get a version of a command (assuming it exists) in a shell function, and all else fails, report version as "unknown".

True. I can report it as unknown. But the question is whether or not it should show all the errors from missing options. (I suppose I can just redirect stderr to /dev/null and if something works repeat it .. otherwise it will be ignored - but does that sound like a good idea to you or can you think of a reason to show all the invalid options?).

If that sounds good I can do that hopefully tomorrow. I did get some checks in but more have to be added. There were also some typos fixed.

You might wish to special case various commands such as true(1) in that shell function. :-)

It would be funny if true returned false yes. I guess that is what you mean?

[xexyl]

.. in what order should these be tried in? Finally as for strings I can do that but how many lines should I show?

We don't know: something for you to figure out. :-)

Well that’s very helpful! But no. It’s fine. This discussion is good though I will be leaving soon for the night. Going to bed later didn’t help (as usual) so I might as well try getting a little extra sleep.

Again, we suspect a shell function that tries things in some canonical order will help. Plus, as we suggested above, certain commands like true(1) don't have --version, nor -v, nor -V, nor ...

Well that’s true 😆 we might just say it’s true

$ strings /usr/bin/true
@(#)PROGRAM:true  PROJECT:shell_cmds-278

Yes. I suggested that one. But then it’s not consistent with how many lines to filter. I don’t think trying to collect patterns like say an antivirus does (not that that’s the only thing that they do) is a good idea and it would be unsustainable anyway.

BTW: You will need to determine what happens when you find a command is a built-in to the shell. For example on macOS under zsh:

Hmm good point.

$which true
true: shell built-in command

however:

$ whereis true
true: /usr/bin/true /usr/share/man/man1/true.1

However for macOS, under bash(1):

$ which true
/usr/bin/true

All of our scripts in this repo use:

#!/usr/bin/env bash

so the bash(1) result is probably the most important to report.

Just to be clear: you mean that I can assume (dangerous though that can be .. one of my personal quotes might amuse you there but I am typing this on the phone and about to go so it will have to be another time or not) that which will work okay because in bash it’s not a built in? Or do you mean something else

[lcn2]

Just to be clear: you mean that I can assume (dangerous though that can be .. one of my personal quotes might amuse you there but I am typing this on the phone and about to go so it will have to be another time or not) that which will work okay because in bash it’s not a built in? Or do you mean something else

We are simply showing the variance for some commands for which there is a builtin that masks an executable in some cases for some shells. Better to look at what bash does for this repo, perhaps.