suggested option for copydir: log= as an alternative to tee=

[tinker2much]

My experience when using rsync is that, if I use it at all, I use it for LOTS of files. With the standard -a flag, there's no detailed listing of what was copied. So, I often add the -v switch to print a line in the output for each of the transferred files. Thus, lots of output. Perhaps TOO much output.

When using copydir, I would like the option to have the rsync detail go only to the separate log. IOW, instead of "tee", where the detail goes both to the sdm logs and a separate log, I would prefer a "log=" option where the detail went only to the separate log.

At least to me, that would be a more useful or common option than tee. Really, with -a there's little or no regular output, so why bother to tee it anywhere? And with voluminous output, why confuse the sdm logs?

Or, to cut it even finer: in the proposed log option, have stderr go to _both_the sdm and separate logs, while stdout goes only to the separate log.

[gitbls]

Great idea!

[tinker2much]

I don't think this is in 11.6?

(nudge)

[gitbls]

No, it's not. Thanks for the nudge. Next release for sure.

[gitbls]

Looking at this. Should the args be:

• stdout= and stderr=
• log= (both stdout/stderr in one file)
• output= and error=

[tinker2much]

I lean towards the first line. Clearer to those who are likely to be using this.

How would tee interact with these or is tee going away?

[gitbls]

Thanks. tee time has passed.

[gitbls]

stdout and stderr are supported in v11.7

[tinker2much]

I'm trying this out. My log includes this:

/mnt/sdm/usr/local/sdm/plugins/copydir: line 33: /mnt/sdm//home/pi/Downloads/bookworm64-full_copydir.stdout: No such file or directory
/mnt/sdm/usr/local/sdm/plugins/copydir: line 34: /mnt/sdm//home/pi/Downloads/bookworm64-full_copydir.stdout: No such file or directory
/mnt/sdm/usr/local/sdm/plugins/copydir: line 35: /mnt/sdm//home/pi/Downloads/bookworm64-full_copydir.stdout: No such file or directory

and then this:

> Plugin copydir: Keys/values found:
   from: /home/pi/Documents/sdm/csrc/
   to: /
   rsyncopts: -av
   stdout: /home/pi/Downloads/bookworm64-full_copydir.stdout
   stderr: /home/pi/Downloads/bookworm64-full_copydir.stderr

So, are those two files supposed to go into the image, as the first chunk implies, or into the host, as the second chunk implies?
I assumed that the destinations for stdout and stderr were within the host.

[tinker2much]

I looked into the meaning of the failures in the first block of lines, and I think it's because the Downloads directory doesn't exist, and therefore the copydir plugin was unable to redirect the rsync's stdout and stderr text there. (The actual copying of the data didn't happen either; I looked into the image, and none of the expected stuff is there.)

Lines 33, 34, and 35 in the plugin are the following:

echo "rsync $aa $rsyncopts $from $to" >>$stdout
rsync $aa $rsyncopts $from $to >>$stdout 2>>$stderr
echo "" >>$stdout

So any code trying to redirect to files in a non-existent directory failed. I will try specifying a location like "~" that's guaranteed to be there. Irony bump: the copydir would have CREATED the Documents directory...

[gitbls]

The intention is that stdout and stderr are written into the IMG, just as /etc/sdm/history is, making the IMG more self-documenting

The second example (keys/values found) is printed by a generic function that only reports what is found in the plugin invocation.

There are a couple of options here:

• Always write the logs to the /path/to/log specified. If you want it to go into the IMG you would need to precede with /mnt/sdm to do so, otherwise it would go to the host (if nodirect is specified), or into the IMG at /path/to/log (if nodirect IS specified). Of course, this is won't work well if $SDMPT != "/mnt/sdm". What should be done in that case??? And, note that if nodirect IS specified, the phase 0 copy to staging woudl go to the host and the 2nd copy would go to the IMG.
• Leave as is. Not specifying nodirect (which does a direct copy into the IMG in Phase 0) will have the logs go to /path/to/log in the IMG. Using nodirect (which results in 2 copies...one to stage in Phase 0 and one from stage to final destination in post-install) would result in logs being written into the IMG at $SDMPT/path/to/log. Well, it will once the buglet I just spotted is fixed.
• Rethink the logging because it's too complex as it is now.

Your thoughts?

[tinker2much]

The intention is that stdout and stderr are written into the IMG, just as /etc/sdm/history is, making the IMG more self-documenting.

I think we have different mindsets. To me, the image IS the document, self-evident, a child meant to leave home and go do its thing. The host (the parent) remembers how much it spent on orthodontia, and whether Mary ever got the chicken pox. No need to duplicate those bills or facts or history and tuck them in Mary's suitcase as she leaves. If she needs to know any of that later, she can return home and ask Mom.

I never actually look in the image for the results of the configuring or burning. Since sdm is invoked on the host, I look for status and errors and history on the host; in fact I take whatever verbiage sdm produces (both stdout + stderr) and tee them off into files of my choice. The invoking command line / script is the record of the user's intention, those redirected files record the results, and both reside on the host.

Given that mindset, I assumed that the output of the copydir, or actually the rsync contained within copydir (voluminous as heck since I set -av) would be going to the host, like the other stdout/stderr verbiage, with the copied directory being sufficient evidence of itself in the image.

I can't speak to the additional complication of direct/nodirect, since I don't need to do nodirect.

Another option: add a way for the user to specify destination=host or destination=image, with the default being whichever one YOU like, and we'll both be able to do what we want. This also means the user doesn't have to worry about /mnt/sdm.

[tinker2much]

It was for sure my problem that I was trying to put the copydir stdout and stderr to ~/Downloads in the image, which didn't yet exist. I was able to place them at /home/pi.

... but I would still like to push for some option that would let me place them on the host.

[gitbls]

As you wish...

After further consideration, I've removed the nodirect option, and the path for stdout and stderr are not modified.

This means that these files will likely always be written on the host, unless you manually force it into the IMG.