Closed michaelsjackson closed 4 years ago
Hi,
While I was following the principle of "no spaces or special characters in file names" for decades, I switched to "spaces are OK but no special characters in file names" about eight years ago. Recently, I switched to "any character you like in file names" as there are no reasons left where I do think that this is adding complexity or errors.
If you won't follow my personal rationale here, you can simply change TEXT_SEPARATOR = ' ' # between old file name and inserted text
with TEXT_SEPARATOR = '_' # between old file name and inserted text
at the beginning of appendfilename/__init__.py
(or whatever the appendfilename
script is named in your system).
If I get the feeling that this is a frequently asked request (so far, you've been the only one), I may add a command line parameter and/or a configuration setting for this character.
Thanks a lot. Probably I am the only one testing your system. :)
Hehe. No, you're far from being alone.
I think that spaces (as well as special characters) are very much embraced also by people like us with a decent GNU/Linux background and shell experience. My zsh is comforting me with nice tab completion handling all those special cases very fine. I really don't have any argument to omit my German umlauts such as ö, Ä or ß in file names.
Ok, I can give you a new view angle. If you want to work only inside your shell you might be correct. But what if you also work with 100 other programs, and some of them have trouble dealing with those spaces or Umlaute or something? Just because of those spaces I would need to solve those problems because of various reasons.
Example 1: eaglemode, does not like spaces in file names, at least not if you want to use also certain advanced techniques.
Example 2: emacs, org-mode, latex, pdf export might cause various problems if you have Umlaute in the document, or java code as source block, in theory it should accept UTF, but only in theory, in certain scenarios they are not accepted. Thus we need to solve that problem there as well. Or you add an image into a latex document, of course always via org-mode, just because there are some Umlaute or spaces in file or directory names, the image will not be displayed in the exported pdf.
I know all these cases because I am dealing with them daily. Removing spaces, removing Umlaute, solves all above mentioned problems. It is not just a matter of the used shell version, but all the various programs you are working with, or will work in future. Anyway, thanks for your response. If I would see there is no satisfying solution, I would just stop using your techniques here, because in the end I want my tools to work, always, not getting additional problems. While adding some extra nice functionality, I do not want to get new problems which did not exist before. I hope you understand my point a bit better now. Thanks for reading this long text. :)
Oh I get your pain. I'm using Org and LaTeX (also without Org/Emacs export) myself.
The thing is that the files I modify using my tools such as appendfilename
, date2name
, or filetags
are not files I'm using with Org or LaTeX. Almost every file I modify using my tools is part of "a JPEG photograph from my mobile" or "a PDF document I scanned from paper" or "a downloaded reference file from the Internet".
For the other cases you mentioned, I'm aware of issues and therefore I just refrain from introducing them. However, just because I keep TeX image file names short and matching [a-zA-Z0-9_]
does not mean that I restrict myself from using the full set of characters for the other files.
YMMV.
The definitions could be rewritten to contain Karl's space as an adjustable default.
Reading the __init.py__
file in question, I identify three separators. The first one, FILENAME_TAG_SEPARATOR
once defined outside functions, used twice in the USAGE
block but not in functions to modify the files. The second, BETWEEN_TAG_SEPARATOR
, is introduced with # between tags (not that relevant in this tool)
and used only once in the USAGE
block. Thus, the script's action on files does not depend on them and (if USAGE
were reformulated, vide supra) could be removed.
After definition and four occurences in USAGE
, the third separator, TEXT_SEPARATOR
, actually is used four times in the functions. This one could be defined as an adjustable parameter with default value; either with contemporary argparse
like in
#!/usr/bin/env python3
"""Approach with the more modern argparse."""
import argparse
parser = argparse.ArgumentParser(description="""This is a greeter.
As you see, f strings do not function here: {f}.""")
parser.add_argument("-n",
"--name",
metavar="name",
default="World",
help="""Specify explicitly the name to greet. By default,
this is "world".""")
f = str("Echo")
args = parser.parse_args()
print("".join(["Hello, ", args.name, "!"]))
.or. remaining in the elder optparse
(no longer developed, reference) by
#!/usr/bin/env python3
"""Approach with the elder optparse."""
from optparse import OptionParser
parser = OptionParser(description="""This is a greeter.
As you see, f strings do not function here: {f}.""")
parser.add_option("-n",
"--name",
metavar="name",
default="World",
help="""Specify explicitly the name to greet. By default,
this is "world".""")
f = str("Echo")
(options, args) = parser.parse_args()
print("".join(["Hello, ", options.name, "!"]))
If adopted, this could both i) retain the pattern @novoid already is used to and ii) add the flexibility @michaelsjackson suggested. I equally like the suggestion, too, however did not spot (yet) which function(s) may/should use the result of an additional
parser.add_option("-s",
"--separator",
metavar="separator",
default=" ",
help="""Specify the text separator (default: " ").""")
as parameter.
Thanks @nbehrnd for the suggestion,
I just released a new version that includes the additional --separator
CLI option. I hope that this is an improvement for you.
Please note that you can define a shell alias in case you want to change the separator for good: alias appendfilename="appendfilename --separator=\"_\""
(untested).
Happy new year
Indeed, initial work on the CLI with the version revised today feels more comfortable now. Again, diffing the old vs. the new script and your comment are instructive for me, too.
Thanks and a productive 2022.
@nbehrnd, please do never assume that I'm a good programmer! Mostly, I'm happy when it works on my machine which is not something a good programmer should depend on.
@michaelsjackson To provide some additional perspective, if you run appendfilename with the optional --separator=
flag, you not only may use any English character [a-zA-Z]
plus any of #!@$%*_+=-
as a visible sign (plus the explicitly defined space). E.g.,
norwid@carnot2:~/Desktop/lab$ appendfilename 2022-01-09T14.30.19_test.txt --smart-prepend --separator=! --text book --verbose
DEBUG 2022-01-09 14:31:30,433 text found: [book]
DEBUG 2022-01-09 14:31:30,434 extracting list of files ...
DEBUG 2022-01-09 14:31:30,434 len(args) [1]
DEBUG 2022-01-09 14:31:30,434 1 filenames found: [2022-01-09T14.30.19_test.txt]
DEBUG 2022-01-09 14:31:30,434 iterate over files ...
DEBUG 2022-01-09 14:31:30,434 options.smartprepend is set with ||book|!|2022-01-09T14.30.19_test|.txt
DEBUG 2022-01-09 14:31:30,434 options.smartprepend is set with |<class 'str'>|<class 'str'>|<class 'str'>|<class 'str'>|<class 'str'>
DEBUG 2022-01-09 14:31:30,434 date/time-stamp found, insert text between date/time-stamp and rest
DEBUG 2022-01-09 14:31:30,434 options.smartprepend is set with ||2022-01-09T14.30.19|test.txt|
DEBUG 2022-01-09 14:31:30,434 options.smartprepend is set with |<class 'str'>|<class 'str'>|<class 'str'>|
DEBUG 2022-01-09 14:31:30,434 new_filename is now: 2022-01-09T14.30.19!book!test.txt
DEBUG 2022-01-09 14:31:30,434 renaming "2022-01-09T14.30.19_test.txt"
DEBUG 2022-01-09 14:31:30,434 ⤷ "2022-01-09T14.30.19!book!test.txt"
DEBUG 2022-01-09 14:31:30,435 successfully finished.
Please press <Enter> for finishing...
to enclose the annotation in (for file names rather rarely used) exclamation marks. If it is more than a single word to be added (by --text
/-t
), the string has to be enclosed in quotation marks, e.g.
norwid@carnot2:~/Desktop/lab$ appendfilename 2022-01-09T14.30.19_test.txt --smart-prepend --separator=@ --text "This is a book shelf" --verbose
DEBUG 2022-01-09 14:36:01,473 text found: [This is a book shelf]
DEBUG 2022-01-09 14:36:01,473 extracting list of files ...
DEBUG 2022-01-09 14:36:01,473 len(args) [1]
DEBUG 2022-01-09 14:36:01,473 1 filenames found: [2022-01-09T14.30.19_test.txt]
DEBUG 2022-01-09 14:36:01,473 iterate over files ...
DEBUG 2022-01-09 14:36:01,473 options.smartprepend is set with ||This is a book shelf|@|2022-01-09T14.30.19_test|.txt
DEBUG 2022-01-09 14:36:01,474 options.smartprepend is set with |<class 'str'>|<class 'str'>|<class 'str'>|<class 'str'>|<class 'str'>
DEBUG 2022-01-09 14:36:01,474 date/time-stamp found, insert text between date/time-stamp and rest
DEBUG 2022-01-09 14:36:01,474 options.smartprepend is set with ||2022-01-09T14.30.19|test.txt|
DEBUG 2022-01-09 14:36:01,474 options.smartprepend is set with |<class 'str'>|<class 'str'>|<class 'str'>|
DEBUG 2022-01-09 14:36:01,474 new_filename is now: 2022-01-09T14.30.19@This is a book shelf@test.txt
DEBUG 2022-01-09 14:36:01,474 renaming "2022-01-09T14.30.19_test.txt"
DEBUG 2022-01-09 14:36:01,474 ⤷ "2022-01-09T14.30.19@This is a book shelf@test.txt"
DEBUG 2022-01-09 14:36:01,474 successfully finished.
Please press <Enter> for finishing...
In linux not having any spaces in file names can have lots of advantages, so is there any way appendfilename uses _ between words instead of spaces? Thanks in advance.