Lsseq

A very unimportant point release of `lsseq`.

I noticed that the output of `lsseq --format shake` didn't follow the conventions of the rest of the `--format` outputs. Since `shake` has been SO LONG deprecated, that I haven't used this option for decades I hadn't noticed that it was an oddball. I checked some OLD documentation for `shake` and redid the output to still be correct - that is, if you were to paste multiple sequences (from `lsseq` output) when calling `shake` from the command line, it should work.

So, fixed the old `shake` oddball output from this:


shake -t 1-15 r1..jpg
shake -t 101-115 r2..jpg
shake -t 1-15 rrr01..ass


to this


r1..jpg -t 1-15
r2..jpg -t 101-115
rrr01..ass -t 1-15



Really, I didn't need to do this because I think NOBODY uses `shake` anymore, I can't imagine that it runs on any machines still. But what the heck, it was bugging me.

In the prior v3.0.2 version of lsseq, doing a --globalSortByTime, when listing "movies" still printed the './' at the head of the string.
Furthermore a double-slash '//' was appearing before the movie-filename (instead of a single-slash directory/file separator.)

So this release properly fixes that harmless bug addressed in the prior release. Harmless because the paths are, in effect, identical as produced by the previous verbose ("buggy") version vs the current more terse version (which is now the same as how image-sequences and cache-sequences are handled) both point to the same file with no errors.

To see the bug, use the following command with lsseq version 3.0.2 vs 3.0.3 in the 'tests' directory of the repo.

$ lsseq -R -P --onlyMovies --globalSortByTime

...and compare the results.

The test-code has been updated to catch these cases better in the future.

The option `--prependPathRel` should never have printed "./" at the head of any line of output. It's redundant, clutters up the output, and doesn't add any helpful information. However the presence of "./" in a line of output up until this release was totally harmless apart from aesthetic considerations.

Therefor this is a design-bug fix, and with this fix `lsseq --recursive --prependPathRel` and `lsseq --recursive --prependPathRel *` (i.e. with the globbing wildcard) NOW produce the exact same results in any given directory from which the above two commands are run.

Stripping "./" from the head of the relative path will not break any scripts that might be using this option, because the path with or without "./" refers to the exact same set of files.

(Note: `v3.0.1` missed adding the bugfix for `--prepentPathRel` to cache and movie sequences, as well as when outputting in a different `--format` (like `nuke`, or `glob`) when using `--prepandPathRel`. This release fixes that oversight.)

The option `--prependPathRel` should never have printed "./" at the head of any line of output. It's redundant, clutters up the output, and doesn't add any helpful information. However the presence of "./" in a line of output up until this release was totally harmless apart from aesthetic considerations.

Therefor this is a design-bug fix, and with this fix `lsseq -R -P` and `lsseq -R -P *` (i.e. with the globbing wildcard) NOW produce the exact same results in any given directory from which `lsseq` is run.

Stripping "./" from the head of the relative path will not break any scripts that might be using this option, because the path with or without "./" refers to the exact same set of files.

Anyway, upping to `v3.0.0` make it more obvious that there are some details (when installing) that need to be paid attention to. For example, possibly rebuilding `/usr/local/venv` with a version of `python3>=3.7`, and reinstalling `lsseq`, `renumseq`, etc. again.

Now `lsseq` is able to trap `stderr` output from running `ls`, and supressing the message if `--silent` was invoked on the command line.

Also, we grab the error codes from the call to `ls` bringing us to the next point...

Better ERROR codes and warning messages overall.

Better error handling is now provided and `lsseq` returns different error codes, as such:


EXIT_NO_ERROR = 0 Clean exit.
EXIT_LS_ERROR = 1 A call to 'ls' returned an error code.
EXIT_ARGPARSE_ERROR = 2 A bad option was passed to lsseq. Exit lsseq.
EXIT_LSSEQ_SOFTLINK_WARNING = 4 warning - broken softlink found
EXIT_LSSEQ_PADDING_WARNING = 8 warning - two images with same name, same frame-num, but diff padding


Even better, those error codes above are combined bitwise to return as much information as possible.

For example, an error code of `12` means we got a warning of a broken softlink AND we found more than one file in a sequence, with the same frame-number, but different frame-number-padding. These codes are returned regardless of whether or not `--silent` or `--quiet `were invoked.

Also, we now have improved warning messages in both information and clarity.

Zero-padding was not being enforced by the library (`dateparser`) which was being used to parse the date passed to `--onlyShow`. This is fixed now to enforce zero padding in the month, days, minutes & seconds. Eg. Before this fix `--onlyShow since 200731` would have listed sequences with modification dates after March 1 2007, instead of July 31, 2020, which it NOW correctly does, as `200731` should be interprted as YY MM DD, and not YYYY M D as the dateparser library was doing.

Also, slightly better `--help` output was added.