You are not logged in.
Is there something like "quote" to add a prefix and a suffix to what's coming out of the shell pipe ? eg: suppose some tool is outputting like the following:
/something/one/
/something/two/
/something/three/And now suppose I want to add prefixes and suffixes to the above like formatting and color escape sequences to present output better formatted:
∙ [/something/one/]
∙ [/something/two/]
∙ [/something/three/]where the same paths are now highlighted with some color; that's no problem at all, but, I am having a hell-of-a-time piping to sed to replace the beginning and ending of the lines with whatever I need (the easy part) but I am not able to insert color escape sequences I do all the time with /usr/bin/printf. The sed expressions being delimited with single quotes make it very difficult to insert escape sequences already in some variable; eg:
whatever | sed 's:^:∙ \[:' - | sed 's:$:\]' -vs
whatever | sed 's:^:∙ \["${colorGREEN}":' - | sed 's:$:"${colorDEFAULT}"\]' -which obviously doesn' work (like swapping single vs double quotes).
I know I am a newbie but needless to say I can't believe the time I waste attempting to do such trivial things in BASH vs coding them a proper language -and yes, I think BASH is such a thing for prototypes or trivial things but these things sometimes drives me mad --not complaining, just stating where I am standing up right now. Maybe it is that I always used to have a library at disposal for string management and-what-not and now I have to think of lots of different tools vs APIs and the like; I coded a lot of complex scripts in the past in PowerShell and I am now spending lots of time to try to figure out such things like how to format dates. Its like each tool have a completely different vision of the world -not even the minimal standard. This last section sounds like a rant, or it is directly a rant. excuse me, I am really happy with arch and won't be reverting back to Windows, call it rite-or-passage or whatever, but sometimes, it is frustrating. On the other side the community here is extremely helpful -and with lots of patience I guess. Now (I think) I understand how the two OS approaches differ: Windows being a API-based OS while UNIX-derived-ones being tool-based ones with all the pros and cons of each other -I am referring to user-land here, obviously.
Offline
printf "* [%s]\n" "${arr[@]}"Offline
whatever | sed 's:^:∙ \["${colorGREEN}":' - | sed 's:$:"${colorDEFAULT}"\]' -which obviously doesn' work...
It's not obvious to me. Why doesn't it work for you? Specifically, what output does this give you, and how does that differ from your intended goal? Note that you need not pipe sed to sed ... that's pointless as you're already using sed. Also there's no need to explicitly put the dash as an argument:
whatever | sed 's:.*:∙ \['"${colorGREEN}"'&'"${colorDEFAULT}"'\]'Though, personally I'd get rid of all the hoops jumped through to use those variables. Variables should be used to make things easier and more readable, and thus should not be used when they have the opposite effect:
whatever | sed 's:.*:∙ ^[[32m&^[[0m:'Note that the "^[" in that needs to be an actual escape character which can't really be copy-pasted (e.g., type it in vim with Ctrl-v Esc). Alternatively you could replace it with \033.
EDIT: if you want actual square brackets printed, add those as well - I wasn't quite sure what they were doing in your sed command: those don't need to be escaped with a backslash. So perhaps you want something like this:
whatever | sed 's:.*:∙ [^[[32m&^[[0m]:'Last edited by Trilby (2022-06-21 03:26:19)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
(gnu) sed treats "\x1B…" as escape sequence so "\x1B[1;32m" gets you a nice bold green.
Online
What trilby said is the normal way to do it. However, as an alternative, you could also write a very simple command that does this for only one string (not every line) and then parallelize it. The simple command in this case is
echo '∙ \[foo\]'but you can also just write your own script called bar.sh and then the command is just "./bar.sh".
For parallelizing you'll see people recommend xargs, but I find GNU Parallel more convenient:
$ whatever | parallel echo '∙ \[{}\]'
∙ [/something/one/]
∙ [/something/two/]
∙ [/something/three/]If bash quotes give you trouble, you can easily convert bar.sh to a simple Python script or something like that.
In this case I'm passing each line as a CLI arg, but of course GNU parallel has toggles for feeding it to STDIN instead. It also has a toggle to preserve the order of output.
Last edited by lfitzgerald (2022-06-24 03:43:55)
Offline
parallel or xargs are great when the process run on each line of input is computationally intensive - but they are horrible for simple text processing as the paralellization gives little to no gains while the overhead of implementing the parallelization is substantial. There is no need for a huge number of "echo" commands when one sed will do.
Last edited by Trilby (2022-06-24 03:59:47)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Thanks for your answer and sorry for not replying back in time -couple of unexpected things; call it living ![]()
Also there's no need to explicitly put the dash as an argument:
I already know this but I like it this way because to me it is more meaningful anyway. Per the man page It is optional and being optional doesn't mean don't use it regardless whether it is needed or not. Personal preference.
Though, personally I'd get rid of all the hoops jumped through to use those variables. Variables should be used to make things easier and more readable, and thus should not be used when they have the opposite effect:
Regarding your comment "Variables should be used to make things easier and more readable" I am using variables because the color sequences I use may change and eventually I am not going to comb through dozens of files to search and replace them. So no, hard-coding them is out-of-the-question.
Offline
parallel or xargs are great when the process run on each line of input is computationally intensive - but they are horrible for simple text processing as the paralellization gives little to no gains while the overhead of implementing the parallelization is substantial. There is no need for a huge number of "echo" commands when one sed will do.
Didn't know it but not surprised at all. Mental note made. Thanks.
Offline
(gnu) sed treats "\x1B…" as escape sequence so "\x1B[1;32m" gets you a nice bold green.
I am currently using \e[#;#m sequences; eg: \e[1;32m for green and \e[0m to revert back to the default one; with my custom colors defined in variables in the system-wide BASH profile to be consumed either by non-GUI and GUI scripts.
Why \e instead of \x1B ?
Because when many years ago I researched the subject I came across those sequences -and by the way I didn't have the GUI installed back then, it was all withn the native linux console -which by the way was the best decision since I learned a lot outside a GUI environment where many things are taken for granted.
Offline
Thanks for your reply lfitzgerald.
If bash quotes give you trouble, you can easily convert bar.sh to a simple Python script or something like that.
To be quite frankly I thought a lot on this over the last two weeks, precisely about all these script issues/annoyances. Besides my BASH custom installation scripts (which I am really happy with since I can now reinstall everything already-customized-to-the-bone in an hour or-so) I am starting to seriously think to rewrite every script I have in a proper language and so be with it; almost sure in D. I am proficient in D right now but I still lack experience writing scripts with it besides some tests I did over the weekend. We'll see where this ends. I'll keep my custom installation script as-is since I won't have access to the D runtime while installing, but everything else could be a go provided the final code won't end to cumbersome/whatever.
Offline
I am currently using \e[#;#m sequences …
Note that the "^[" in that needs to be an actual escape character
(gnu) sed treats "\x1B…" as escape sequence
Why \e instead of \x1B ?
Because bash (along a couple of other shells) interprets it as (octal) 033, https://tldp.org/HOWTO/Bash-Prompt-HOWT … ences.html
(gnu) sed treats "\x1B…" as escape sequence
Note that the "^[" in that needs to be an actual escape character
If you want to gnu-sed an escape sequence into anything, you'll have to use \x1B - because 0x1B is 033 is 27
https://en.wikipedia.org/wiki/ASCII#Control_code_chart
Online