On Wed 26 Apr 2023 at 14:33:03 (+0000), Albretch Mueller wrote: > On 4/26/23, to...@tuxteam.de <to...@tuxteam.de> wrote: > >> a) encode the string name as base64 > >> b) calculate the sha256sum of §a > > > > Why the detour over base64? > > because I would like to include the three strings in the file descriptor: > a) the crazy long name > b) its base64 representation
The base64 command wraps the output, in case you didn't notice. > c) §b's sha256sum representation which is the one used for the file > name and the log of the download. I guess you need the expense of sha256 rather than md5 as you're downloading the entire web? > I would like to make this scheme "fool (and fail) proof" as they say. > There is no way in earth that a file system messes with all three > aspects of it. > > >> c) use §b as file name (of course, leaving the original extension as it > >> is) > > > > Why the extension? DOS nostalgia? > > The local copies should represent the web URLs as close as possible > in order to minimize "what came from where" kinds of confusions. Also > from the same URL you would then download the corresponding pdf file > with exactly the same name, the only difference being the extension. The extension is part of the name. If you preserve it as is, what happens when it contains a "funky" character. > >> // __ $_SHA256: > >> |7d5895cb24ab49692a8ad495e036074fec8e61b22040544f02a9b69c926dbdeb -| > > > > > > I only see harmless hexadecimal chars there. > > > >> I am trying to avoid funky characters and sha256sum --text still > >> generates them!?! > > > > Where are there "funky chars"? > > This is the first time I have seen blank spaces and hyphens in a text > segment's sum. Those characters might be confusing. You calculated the sha256sum of stdin. - is the name of the input file you encoded. Duh. Cheers, David.
