2.13 output became too verbose

[sergeevabc]

Windows 7 x64 user here.

$ brename2.12.exe -S "" -R -p "\.startup" -r "_startup"

[INFO] main options:
[INFO]   ignore case: false
[INFO]   search pattern: \.startup
[INFO]      skip filters:
[INFO]   include filters: .
[INFO]   search paths: ./
[INFO]
[INFO] checking: [ ok ] 'Keepass\.startup' -> 'Keepass\_startup'
[INFO] 1 path(s) to be renamed
[INFO] renamed: 'Keepass\.startup' -> 'Keepass\_startup'
[INFO] 1 path(s) renamed

Except for the redundant checking and nerdy rather than vernacular presentation of renaming conditions with too much [INFO] SHOUTING, I'm happy with it. Especially considering that @shenwei356 implemented my proposal about undoing changes.

Now, let's update to 2.13 and see what happens.

$ brename2.13.exe -S "" -R -p "\.startup" -r "_startup"

[INFO] brename v2.13.0
[INFO]
[WARN]
[WARN] The flag -w/--case-insensitive-path is switched on Windows by default,
[WARN] where the path is case-insensitive in file systems like FAT32 and NTFS.
[WARN] If you are using a file system in which paths are case-insensitive,
[WARN] please use -W/--case-sensitive-path.
[WARN]
[INFO] ---------------- main options ------------------------
[INFO]
[INFO] search mode:
[INFO]  recursively rename: true
[INFO]       maximum depth: 0 (0 for no limit)
[INFO]   include directory: false
[INFO]      only directory: false
[INFO]
[INFO] path filters and search pattern:
[INFO]    search pattern: \.startup
[INFO]       replacement: _startup
[INFO]       ignore case: false
[INFO]
[INFO]      skip filters:
[INFO]   include filters: .
[INFO]
[INFO] path overwrite checking:
[INFO]   case-insensitive path: true
[INFO]          overwrite mode: 0 (reporting error)
[INFO]
[INFO] miscellaneous:
[INFO]      disable undo: false
[INFO]   only list paths: false
[INFO]           dry run: false
[INFO]
[INFO] ------------------------------------------------------
[INFO]
[INFO] search paths: ./
[INFO]
[INFO] checking: [ ok ] 'Keepass\.startup' -> 'Keepass\_startup'
[INFO] 1 path(s) to be renamed
[INFO] renamed: 'Keepass\.startup' -> 'Keepass\_startup'
[INFO] 1 path(s) renamed

• The executable has increased by 459 264 bytes, although there are few changes.
• The amount of information has grown so much that it simply did not fit on my laptop screen. Why would I need such a detailed explanation of the renaming conditions if I already spent time studying the command line flags in the manual, picked the necessary ones and now I just want the app to fulfill its purpose?
• The app scared me with a multi-line warning about a new flag, which is enabled by default and should not shout of itself precisely because of being a default one.

This is what I expect to see:

$ brename.exe -S "" -R -p "\.startup" -r "_startup"

brename x.yz by Wei Shen, https://github.com/shenwei356/brename/

[OK] 'Keepass\.gogogo' -> 'Keepass\_gogogo'
1 path(s) renamed

The rest (timestamp, message type, renaming conditions, etc), if at all necessary, should be displayed if a dedicated flag is specified, thereby explicitly asking the app to increase the verbosity of logging.

[shenwei356]

Haha 🤣, thanks for your comment. It is kind of verbose. It's meant to provide more details.
You can add -q/--quiet to make it quiet, which only reports for errors.

$  ls
A.txt B.txt

$ brename -p .txt -r _txt -q

$ ls
A_txt B_txt

$ brename -p A -r B -q
[ERRO] checking: [ new path existed ] 'A.txt' -> 'B.txt'
[ERRO] 1 potential error(s) detected, please check

[sergeevabc]

Alas, -q makes the app too quiet.

Imagine you are in a car, its windshield is dirty, and you press a button to clean it. At present, the cleaning is accompanied by readings from a dozen sensors — it makes you keep an eye on everything and eventually causes anxiety. Using -q turns this process into wandering in the dark: the lights go out, a pause of unknown duration, then the lights come back on and the windshield, as in fairy tales, is already clean. We need a golden mean that provides sufficient feedback w/o overwhelming with details.

I call it attention-friendly output, since human attention is a scarce commodity.

[shenwei356]

I understand now, you're right.

I just set -v 2 as the default log level. It's more concise now. -v 0 outputs all verbose information as before.

$ ls
A.txt     B.txt

$ brename -p A -r B
[ERRO] checking: [ new path existed ] 'A.txt' -> 'B.txt'
[ERRO] 1 potential error(s) detected, please check

$ brename -p A -r A

$ brename -p txt -r text
[INFO] renamed: 'A.txt' -> 'A.text'
[INFO] renamed: 'B.txt' -> 'B.text'
[INFO] 2 path(s) renamed

$ brename -u 
[INFO] rename back: 'B.text' -> 'B.txt'
[INFO] rename back: 'A.text' -> 'A.txt'
[INFO] 2 path(s) renamed

Please try the new binary:

brename_windows_amd64.exe.tar.gz

[shenwei356]

@sergeevabc How's the new version?

[sergeevabc]

@shenwei356, it crashes. I'm trying to understand the reason for the crash.

$ brename.exe
Exception 0xc0000005 0x8 0x0 0x0
PC=0x0

runtime.asmstdcall()
        /usr/local/go/src/runtime/sys_windows_amd64.s:65 +0x75 fp=0x22fca0 sp=0x22fc80 pc=0x46c355
rax     0x0
rbx     0xb8e3c0
rcx     0xbe34c0
rdi     0x7fffffde000
rsi     0x22fea0
rbp     0x22fde0
rsp     0x22fc78
r8      0x0
r9      0x22fee0
r10     0xbb5278
r11     0x21
r12     0x22fec0
r13     0x1
r14     0xb8dd60
r15     0x0
rip     0x0
rflags  0x10293
cs      0x33
fs      0x53
gs      0x2b

[shenwei356]

Are you using Windows 7? Go 1.21 requires at least Windows 10 or Windows Server 2016.

Try this one, compiled with Go1.20.
brename_windows_amd64.exe.tar.gz

[sergeevabc]

Are you using Windows 7?

Sure. I mentioned this in the first line of the current issue.

I use Windows 7 and will continue to do so. The last OS which they tried to make polished enough to last, like a good hammer or wrist watch. What happened next was never meant to be a progress like before (NTFS instead of FAT32, for example), but a forced change of the profit model to software as a service (SaaS). It resembles the relationship between a drug dealer and an addict, to whom a weekly dose of patches is supplied to feel less anxious about a poorly made, but undeniably glossy OS.

Your app deals with renaming files. I see no reason why it should stop working under Windows 7. Its descendants offer no breakthroughs related to files I/O. Go language developers want to look relevant, whereas I want apps to be future-proof. Think UNIX apps that are built to last across OSes w/o “do not touch after EOL” fearmongering.

Back to bRename

• Consider adding the name and version of the app as the first line. When the program is just starting to work and has not yet found a single file to rename, I see a black screen without understanding which app doing what. For example:

  $ brename.exe ...
  bRename 2.14 by Wei Shen, https://github.com/shenwei356/brename/
  ...

• I can't get rid of the feeling that you overload the screen with the noise that does not carry a payload and it takes away space that is appropriate to save for lengthy paths (maybe you have a widescreen monitor, but my laptop screen is not wide).

  Consider an alternative:

  $ brename ...
  bRename 2.14 by Wei Shen, https://github.com/shenwei356/brename/
  
  Renaming paths...
  
  [DONE] Autohotkey\_os -> Autohotkey\_startup
  [DONE] DNSCrypt\_os -> DNSCrypt\_startup
  [DONE] Keepass\_os -> Keepass\_startup
  
  3 path(s) renamed, it took 00:00:02.7
  
  $ brename -u .brename_detail.txt
  bRename 2.14 by Wei Shen, https://github.com/shenwei356/brename/
  
  Renaming paths back...
  
  [DONE] Autohotkey\_startup -> Autohotkey\_os
  [DONE] DNSCrypt\_startup -> DNSCrypt\_os
  [DONE] Keepass\_startup -> Keepass\_os
  
  3 path(s) renamed back, it took 00:00:01.9

  • Header with operation type added: Renaming paths, Renaming paths back
  • Prefix [INFO] renamed: changed to [DONE] (something is done, yay!)
  • Single quotes removed
  • Timer added

[shenwei356]

brename_windows_amd64.exe.tar.gz

[sergeevabc]

We're definitely making some progress here, @shenwei356.

Checking...

This message hangs on the screen for quite a long time when the app is running not on SSD, but on HDD. For a minute or so the disk buzzes like mad and we only know that some kind of check is underway. What kind of check is that? Let's explain it more clearly: “Looking for paths that match your pattern...”.

Renaming...

14 path(s) renamed in 45.8626232s

Renaming paths back...

14 path(s) renamed in 25.0014ms

In the second case, the word “back" is missing. This is important because if there are many paths (think multiple screens of paths), then at the time of completion we no longer see the header “Renaming paths back...” and we might think that there was a renaming operation, not a restoration of names.

Why is the timer so granular? Is it the Large Hadron Collider? Or Formula 1 racing? Or the Olympic games? I believe two decimal places is enough (45.86s). Do you have a wrist watch, how many decimal places are there? Also consider using seconds as the minimum unit of measurement (25.0014ms -> 0.02s) and add some humor when it is barely noticeable (<0.00s) like “renamed in the blink of an eye”.

[shenwei356]

It's almost there.

brename_windows_amd64.exe.tar.gz

When searching a path with many sub-directories, the paths will be shown in one line and refreshed to tell users: "I'm working, just be patient and wait!"

[shenwei356]

Recently, I found a new tool https://github.com/ayoisaiah/f2, which even supports Exif attributes~ You can also have a try.

[sergeevabc]

$ brename ...

Searching paths to rename...

  Volume2\SoundsVolume2 Default Whiteerseorangeb\python38certifi1e8e3cd67arar

Renaming paths...

  [DONE] Autohotkey\_os -> Autohotkey\_startup
  [DONE] DNSCrypt\_os -> DNSCrypt\_startup
  [DONE] Keepass\_os -> Keepass\_startup

3 path(s) renamed in 38.116 seconds

• I believe you meant searching for paths (difference explained).
• After the search is complete, there is a frightening residual that consists of parts of different paths (Volume2\SoundsVolume2 Default Whiteerseorangeb\python…). It is more appropriate to clear this field as follows

$ brename ...

Searching for paths to rename...

  [DONE]

Renaming paths...

  [DONE] Autohotkey\_os -> Autohotkey\_startup
  [DONE] DNSCrypt\_os -> DNSCrypt\_startup
  [DONE] Keepass\_os -> Keepass\_startup

3 path(s) renamed in 38.116 seconds

Recently, I found a new tool https://github.com/ayoisaiah/f2…

Good catch, @shenwei356! I have not tried this app in practice yet, but I immediately liked how it greets the user with things that you should consider adopting: the name, version, brief instruction, and a link where to get more information are given.

[shenwei356]

I believe you meant searching for paths (difference explained).
After the search is complete, there is a frightening residual that consists of parts of different paths (Volume2\SoundsVolume2 Default Whiteerseorangeb\python…). It is more appropriate to clear this field as follows

All fixed. Thanks.

brename_windows_amd64.exe.tar.gz

[sergeevabc]

Looks like you forgot to add the refreshing status to the dry-run -d mode.
Then we can call it a day and roll out to the public.

[shenwei356]

Looks like you forgot to add the refreshing status to the dry-run -d mode.

I disable it for -d, because it would be a mess when there are many files to rename.

[sergeevabc]

$ brename ... -d
Searching for paths to rename...

  [OK] Autohotkey\_os -> Autohotkey\_osxxx
  [OK] DNSCrypt\_os -> DNSCrypt\_osxxx
  [OK] Keepass\_os -> Keepass\_osxxx
  Done searching.

3 path(s) to be renamed

'Done searching' is kinda redundant on this screen and could be omitted because '3 path(s) to be renamed' line sums up the search, yes?

[shenwei356]

Right. But here, "Done searching" is printed first, it might be due to different disk speeds.

$ brename -R -p 386 -d
Searching for paths to rename...

  Done searching.                                                      
  [OK] binaries/brename_linux_386.tar.gz -> binaries/brename_linux_.tar.gz
  [OK] binaries/brename_windows_386.exe.tar.gz -> binaries/brename_windows_.exe.tar.gz

2 path(s) to be renamed

Anyway, disabled it in dry-run mode.
brename_windows_amd64.exe.tar.gz

[sergeevabc]

Congratulations, @shenwei356, brename's output looks much better now.