Provide binaries, please about pipe-rename

[mtimkovich]

Added binaries for linux and windows to the latest release (I don't own a mac). I created an issue to automatically create binaries in the future.

[mtimkovich]

No, I don't mind hijacking this ticket. I'm nearly done updating the Github actions on this repo to automatically build and publish the releases, and adding shas to the release should be simple enough.

Adding winget publishing to actions looks easy enough if it's something we wanna do.

[mtimkovich]

Actually scratch that, let's open a new ticket for winget discussion

[assarbad]

@mtimkovich I could also code-sign the Windows builds, if that is desired. We would have to look into if and how it affects stack backtraces, but stripping symbols may be another good idea.

Last but not least for Linux I would strongly recommend to build using something like x86_64-unknown-linux-musl (rustup target list). For a self-contained program this is the best option, providing the widest possible backwards compatibility, if statically linked (sometimes it's even smaller).

As it stands, the binary is tied to a fairly recent version of GLIBC:

$ readelf -V renamer-1.6.5-linux

Version symbols section '.gnu.version' contains 116 entries:
 Addr: 0x00000000000014b8  Offset: 0x0014b8  Link: 5 (.dynsym)
  000:   0 (*local*)       2 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)
  004:   4 (GLIBC_2.9)     3 (GLIBC_2.2.5)   2 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)
  008:   3 (GLIBC_2.2.5)   5 (GCC_3.0)       3 (GLIBC_2.2.5)   5 (GCC_3.0)
  00c:   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)
  010:   3 (GLIBC_2.2.5)   5 (GCC_3.0)       3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)
  014:   2 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   6 (GLIBC_2.17)    3 (GLIBC_2.2.5)
  018:   0 (*local*)       3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)
  01c:   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)
  020:   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   5 (GCC_3.0)       3 (GLIBC_2.2.5)
  024:   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)
  028:   0 (*local*)       3 (GLIBC_2.2.5)   5 (GCC_3.0)       3 (GLIBC_2.2.5)
  02c:   3 (GLIBC_2.2.5)   0 (*local*)       7 (GLIBC_2.18)    3 (GLIBC_2.2.5)
  030:   5 (GCC_3.0)       3 (GLIBC_2.2.5)   8 (GLIBC_2.3)     2 (GLIBC_2.2.5)
  034:   3 (GLIBC_2.2.5)   9 (GLIBC_2.3)     3 (GLIBC_2.2.5)   5 (GCC_3.0)
  038:   a (GLIBC_2.25)    b (GCC_3.3)       3 (GLIBC_2.2.5)   2 (GLIBC_2.2.5)
  03c:   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)
  040:   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)
  044:   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)
  048:   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)
  04c:   c (GCC_4.2.0)     3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)
  050:   d (GLIBC_2.15)    3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)
  054:   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   e (GLIBC_2.3.4)   3 (GLIBC_2.2.5)
  058:   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   5 (GCC_3.0)       3 (GLIBC_2.2.5)
  05c:   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)
  060:   2 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   2 (GLIBC_2.2.5)
  064:   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   f (GLIBC_2.28)
  068:   5 (GCC_3.0)       3 (GLIBC_2.2.5)  10 (GLIBC_2.14)    3 (GLIBC_2.2.5)
  06c:   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)   5 (GCC_3.0)       3 (GLIBC_2.2.5)
  070:   3 (GLIBC_2.2.5)   3 (GLIBC_2.2.5)  11 (GLIBC_2.29)    3 (GLIBC_2.2.5)

Version needs section '.gnu.version_r' contains 4 entries:
 Addr: 0x00000000000015a0  Offset: 0x0015a0  Link: 6 (.dynstr)
  000000: Version: 1  File: ld-linux-x86-64.so.2  Cnt: 1
  0x0010:   Name: GLIBC_2.3  Flags: none  Version: 9
  0x0020: Version: 1  File: libgcc_s.so.1  Cnt: 3
  0x0030:   Name: GCC_4.2.0  Flags: none  Version: 12
  0x0040:   Name: GCC_3.3  Flags: none  Version: 11
  0x0050:   Name: GCC_3.0  Flags: none  Version: 5
  0x0060: Version: 1  File: libc.so.6  Cnt: 11
  0x0070:   Name: GLIBC_2.29  Flags: none  Version: 17
  0x0080:   Name: GLIBC_2.14  Flags: none  Version: 16
  0x0090:   Name: GLIBC_2.28  Flags: none  Version: 15
  0x00a0:   Name: GLIBC_2.3.4  Flags: none  Version: 14
  0x00b0:   Name: GLIBC_2.15  Flags: none  Version: 13
  0x00c0:   Name: GLIBC_2.25  Flags: none  Version: 10
  0x00d0:   Name: GLIBC_2.3  Flags: none  Version: 8
  0x00e0:   Name: GLIBC_2.18  Flags: none  Version: 7
  0x00f0:   Name: GLIBC_2.17  Flags: none  Version: 6
  0x0100:   Name: GLIBC_2.9  Flags: none  Version: 4
  0x0110:   Name: GLIBC_2.2.5  Flags: none  Version: 3
  0x0120: Version: 1  File: libpthread.so.0  Cnt: 1
  0x0130:   Name: GLIBC_2.2.5  Flags: none  Version: 2

This may be desired, but for a software like renamer, I doubt it's intentional.

[mtimkovich]

Thanks @assarbad, both really good suggestions. I already updated the linux release to use that target. I want to automate the release build process and I wonder if code-signing on Windows could be part of that process.

[assarbad]

I already updated the linux release to use that target.

Cool!

I want to automate the release build process and I wonder if code-signing on Windows could be part of that process.

Okay, this is not possible without outrageously expensive means (and even then it's semi-automatic), I'm afraid. The CA/B forum now (since June, IIRC) mandates that the private key for a code-signing certificate need to never leave the hardware on which it was created (unless I completely misunderstand the new rules). Since the signing only ever signs the hash of over the binary, this is still practical even when run against a smartcard. At work, I am working on an attempt to at least make this whole stuff more practical, but I guess other than performing a build and uploading the code-signed binary, I have not much to offer, because I am equally already bound to the key being on a piece of hardware.

Still, the project could simply also publish a file with cryptographic (SHA-256 is considered state of the art) hashes and -- optionally -- a detached PGP signature on that hash file. This way end users have a way to verify integrity of the download. The file hashes are of course equally useful to Linux users.

And in addition to that I could look into the automation for PRs to winget-pkgs upon new releases here (someone created a GitHub action for that, I'll look it up). winget now lets you install from a ZIP archive, which may be a neat way to get a verifiable renamer.exe to the users?! AFAIK it has to be in a ZIP file, but no actual installer is required. (edit: may not be needed, will investigate) The effect would be that installing it on Windows would become as easy as saying winget install --id MarcusBuffett.pipe-rename (or similar, the ID of the package would be up for debate)

Sorry for hijacking this ticket. Should I open a fresh one, @mtimkovich?

[PhiLhoSoft]

Back to Windows binaries, thanks, it works!

A little test:

D:\Temp\Photos
> renamer save*
Error: No replacements found
# Opened Notepad, sensible default on Windows, but not for me…

D:\Temp\Photos
> set EDITOR=C:\PrgFiles\_Text\SciTE\SciTE.exe
# Path created by an Explorer Extension…

D:\Temp\Photos
> renamer save*
Error: Failed to execute editor command: 'C:PrgFiles_TextSciTESciTE.exe'
# OK for me…

Caused by:
    program not found

D:\Temp\Photos
> set EDITOR=C:/PrgFiles/_Text/SciTE/SciTE.exe
# Edit the previous line!

D:\Temp\Photos
> renamer save*

The following replacements were found:

SAVE_20190818_145730.jpg -> Photo_20190818_145730.jpg
SAVE_20200127_091058.jpg -> Photo_20200127_091058.jpg
SAVE_20200304_154723.jpg -> Photo_20200304_154723.jpg
SAVE_20200318_190450.jpg -> Photo_20200318_190450.jpg
SAVE_20200516_113631.jpg -> Photo_20200516_113631.jpg

Execute these renames?: Yes

Good! Perfect, I can use multiple cursors, search/replace, including regexes, in the editor. Simple to use, flexible and effective.
2 MB is a bit a lot for a command line tool, but it is OK. And maybe assarbard can help there too.

[mtimkovich]

Yeah, not sure why the Windows build is 2x the size of the *nix builds, I'll see if that can be fixed.