-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sed script libmode #2
base: master
Are you sure you want to change the base?
Conversation
Just to be clear, my |
$0 in sh is caller's, BASH_SOURCE unavailable
... and, finally, sed-busting performance for shell scripts, with the latest sed-cached used in library-mode. It's about 4x faster than calling sed in a regular shell (and 2x faster than calling the builtin To use this, one has to pre-define SED_DIR, SED_LIBMODE, source the Notes at the end of https://github.com/kstr0k/sed-bin/blob/sed-cached/sed-cached |
I really like the idea, let me look into this |
Also: don't abspath any other files since we don't 'cd' anymore
Sure, have a look and let me know if you want to do things differently. I've converted this to a draft PR. I've just noticed there's a bug (also present on lhoursquentin/sed-bin) whereby a malformed expression ( |
Yeah unfortunately malformed scripts are not handled correctly for the most part, I have a small note in the README regarding this:
Proper error checking in the translator is possible but it would require keeping a lot more state in memory. For instance the translator isn't even aware of curly brackets nesting depth, it just prints them right away and forgets about them. In this specific case ( |
That would be easily checked using " |
All right, I had the chance to take a more in depth look, it's really nice! It's also worth noting that the cached version seems slower than the non-cached one when dealing with big sed scripts, I tried with
My main concern with this approach is that some scripts can have side effects: creating and writing to files with the |
Thanks (it's even cleaner now). Sure; a few more changes will be needed to avoid namespace pollution (
Interesting. It turns out shell string-truncation (e.g.: It just so happened that the combination I was initially using ( I've added a
I was afraid that might be the case. Speaking of which, I wonder, would it be feasible to add a sandbox mode like GNU sed (disable e/r/w)? |
I've been working on a version of the sed script that caches compiled files. In the process, I reorganized the
sed
script to./
files orcd
commands (by usingmake -C
and figuring out absolute paths names forgenerated_file
etc).Besides being extensible and not requiring any hacks, I think the reorganized code is somewhat clearer, so I'm opening a pull request.
FWIW, I've benchmarked (results below)
sed-cached
with a simple sed command. It's about 15 times faster than compiling each time, but still twice as slow as native sed (only 75% slower on busyboxsh
with builtin applets). Yeah, it should be written in C notsh
. But it was a fun as a proof of concept :)I'm curious what you think of this. Perhaps
sed-cached
can make it tocontrib/
. Perhaps a C version would be even faster than sed, and then maybesed-bin
is not so useless after all.for i in $(seq 1 5); do /S/sed-bin/sed s/:/_/g /etc/passwd; done
for i in $(seq 1 5); do /S/sed-bin/sed-cached s/:/_/g /etc/passwd; done
for i in $(seq 1 5); do busybox sh /S/sed-bin/sed-cached s/:/_/g /etc/passwd; done
for i in $(seq 1 5); do sed s/:/_/g /etc/passwd; done