I'd be happy to help you port it to modern, high-quality, readable Perl if that's something you're interested in. Being able to install this by dropping a single Perl file into ~/bin/ would be neat.
My only concerns are:
I do not know what the process of getting comparable tab completion would be in Perl. I depended on the argcomplete package for this feature which I consider to be essential...the clarity of the syntax depends on being a bit verbose, and this is only usable because tab completion makes it fast to use.
Also, I'm somewhat reluctant to develop in Perl, though I'm willing to do it provided the benefit + demand is there. It would be ironic to have learned Perl as a consequence of building a tool whose primary function is to prevent one having to learn Perl.
I'll send you an email to discuss further.
https://fastapi.metacpan.org/source/PERLANCAR/Complete-Bash-...
You can surely omit the lines between =pod and =cur (they are used to create the documentation) and most probably also the "description" parts.
> It would be ironic to have learned Perl as a consequence of building a tool whose primary function is to prevent one having to learn Perl.
It's less ironic than you think, I consider it the bigger irony that Python turned to be the major compatibility problem in all but single-user single-program environments (it's really not trivial to have to work with more Python variants as the dependencies for different code). You can be sure that any Perl 5 skills you obtain can remain quite portable and usable across the different environments.
I've also already written here, I consider Perl significantly "safer" language than Python: when I modify some big Perl scripts, very often the Perl compiler (when used with the "use strict" and -w option) will tell me early enough what is missing for a program to function correctly again, as Perl simply more explicit, in some weird way almost like the typed languages. I never have the same feeling of "it will work" with the modification of the Python scripts.
That "line noise" is actually meaningful, much more consistent than the shell languages, and safer in case of the changes than Python.
I'm not a huge fan of perl but I've been writing my one-liners in it for a few years now and I've had less problems with portability.
https://www.gnu.org/software/gawk/manual/gawk.html#Getting-S...
http://www.grymoire.com/Unix/Awk.html http://www.grymoire.com/Unix/Sed.html
# input line has to be explicitly printed
awk '{gsub(/Jack/,"Jill")} 1' file.txt
# -i will do inplace editing, unlike the awk command
# -i by itself won't work on non-GNU versions, needs backup extension
sed 's/Jack/Jill/g' file.txt
# use single quotes always, unless double is needed
# -p will behave like default sed
perl -pe 's/Jack/Jill/g' file.txt
However, I would agree that initial learning curve is tough for sed/awk/perl. Once you get familiar with their idioms, they become the swiss army knife of cli text processing (along with grep). I have an entire repo dedicated to such tools[1]
[1] https://github.com/learnbyexample/Command-line-text-processi...
Are you responsible for updating the Cargo package? It's the first time I've used Cargo and was wondering how often I should re-run it or check for updates?
one question though, sed is not just search and replace, it is filter + search and replace (without going into arcane commands like n,N,x,h,etc) - filtering can be done based on regex, line number, combination of these two for blocks of line, etc.. Does sd support these?
Python apps which are more than a single script are a non-starter for me. It's a big pain to get everyone on my 120+ person dev team to install it properly, they're all over the place with regard to environments. "Oops, I'm on Python 3.4", or python 2.6, or "I use this other python path"; it's inevitably a headache.
I still consider Perl being, from the portability standpoint, the best language to pre-process a single text line that should be translated to a Perl one-liner which is then executed.
Perl is installed by default on common operating systems.
Aye, but what about the uncommon ones? For your consideration, I'd like to share Perl's configure script:
https://github.com/Perl/perl5/blob/blead/Configure
It's my favorite configure script of all time, but I would hate to be the guy who has to extend it with a new platform :) And I have!
That could be a part of the readme!
Scripts, as you said, might be better off with sed/awk.
Edit: Or, as OP said in a sister comment, using -t and using the Perl command in scripts makes a lot of sense.
On HN, the title of the submission is expected to match the title on the target page, except if the later is a clickbait.
My normal workflow is to write commands, pipe them together as needed, and when I think I am satisfied I'll store to a temporary file. If I really need to be extra sure then I will use my preferred ddiff tool to compare against the original before doing the swap.
I may have mis-interpreted but I hope between this and the unit tests your concerns are alleviated
(Sorry, had to take the easy one. Tooling using something as wide-spread as SQL is definitely a good thing!)
bsed giant_malformatted.json replace '\'' that begins or ends a string with '\"' | bsed replace unquoted 'True' with 'true' | bsed replace unquoted 'False' with 'false'
TEXT PROCESSING DIVISION.
PERFORM REGEXP-REPLACE "LETTER A; LETTER B; ONE-OR-MORE-CHARACTERS;" EMPTY-STRING
. PIC A(2)X(integer01)I imagined a drag and drop interface (sort of like the Scratch programming language) with English descriptors of the functions being performed. You’d make it a web UI or something that generates a bash script you can paste into the terminal.