Can you explain how is awk able to read that variable and not give an error like "awk: cannot open fOo bar1 baR2 bArab (No such file or directory)"? Thanks.

@seshoumara, awk doesn't process any input when there are only BEGIN statements (and optional function definitions).

Cool! I'm just learning awk. Too bad sed can't do that, my favorite command. I changed my answer to not use echo either, based on that post you linked. I've been using echo in every other line in my bash scripts for years :|, time to use printf then.

@seshoumara, GNU sed can do it with \L as you've shown (that syntax coming from vi/ex initially IIRC), POSIX sed can do it with y but you'd need to manually specify all the transliterations (AÁÂ -> aáâ...)

I meant sed can't read a variable directly as awk does in your example by checking the arguments passed; sed always needs an input file, or stdin.

@seshoumara, with GNU sed, there's echo | VAR=$var@ sed 's/^/printenv VAR/e; s/@$//; ...' (on systems without a printenv command, you can replace with echo | VAR=$var 's/^/printf "%s@" "$VAR"/e; s/@$//;...'. POSIXly: printf '%s\n' "$var" | sed -e :1 -e '$!{N;b1' -e '}' -e ...

@StéphaneChazelas Hi. Your comments have been very helpful. I'm learning so much. Thank you. I have some comment though.

if you quote $var, there's no need to add a delimiter at the end

also, that last sed command after printf is not needed at all, the strength of sed is that it can parse one line at a time anyway. If one really needed to put all the input at once in the pattern space, then sed -z would do this with the GNU version

The @ is to work around the fact that sed's e strips trailing newline delimiters. Shells $(...) have the same problem, you'll see I work around it as well in my answer.

aaaa, you sed posix, sorry. I guess -z is not. Even so, I'll let sed do the default one line at a time.

sed -z also causes sed to also output NUL delimited records.

Note that the OP said he wanted to convert to lowercase all but the first word of $var, not all but the first word of each line of $var

you're right, I thought the input is one line only based on the example

I knew that $() removes trailing newlines, I had a problem with that once too, but I'm not that sure about e.

echo|sed 's:^:printf "a\n\n"|xxd:e' puts the same bytes in the pattern space as indicated by xxd, as if you would run that command outside of sed, printf "a\n\n"|xxd.

I didn't notice at the first glance, now I see you print a dot at the end using awk, then removing it after $(). I have to write better scripts, I rarely think of edge cases :(

@StéphaneChazelas ignore that xxd stuf, I'm stupid, the output of xxd is what's put in pattern space. Without, strangely, e deletes only one trailing newline, not all.

echo|sed -n 's:^:printf "a\n\n":e;l'

You're right, my bad. It only removes one (as $(...) should do but doesn't), so that @ trick is not necessary there.

and in sed posix you need all those -e's? I'm used to doing it like sed ':loop;$!{N;bloop};...'

Most people don't think of the trailine newline edge case. They shouldn't have to, it's really a design bug in shells. dirname for instance is meant to be used as dir=$(dirname -- "$file") || exit, you don't want to have to write dir=$(dirname -- "$file" && echo .) || exit; dir=${dir%.}. So most people take the view that they use dirname and command substitution in the way it was intended to be used, and if that doesn't work in those edge cases, the bug is on the shell, not on the script

In traditinal sed implementation, :loop;x defines a loop;x label. You can't have anything after the :, b, r, w, #... commands, and you need a ; before } to separate from the previous commands.

And I thought I'm pretty good in bash and especially in sed :))

I know you can't have anything after i,c,a,r,w,e; but in GNU sed at least you can continue after :;b,t,} and no ; is needed before }. I hate all these different implementations.

Until now I was living only in the GNU Linux world, a few days ago for the first time I had to run a sed script using the busybox version, it didn't run, because I use GNU extensions all the time, I got so much used to them. That's why I don't know what is working on a version and what is not, what is portable (posix I assume) and what is not.

@StéphaneChazelas Thank you for the good discussion, I'll try to remember some points here. Should we delete the last 4 comments from your submission? (starting with @seshoumara, GNU sed can do it with \L as you...)

it's not relevant to your awk script

The POSIX spec (pubs.opengroup.org/onlinepubs/9699919799) is a good starting point to write more portable scripts (though busybox is yet another story as it's cut-down versions of some of the POSIX utilities with many GNU extensions)

@StéphaneChazelas should we delete the last 3 or 4 comments from your awk answer? They talk about sed, so they're not relevant.

@seshoumara Having spent decades on usenet before stackexchange doing the same kind of thing I do now on SE, I personally don't share the SE view that comments are transient things. Discussion can be good, and the archive of that discussion be useful. If a comment has useful information that is not worth adding to the question/answer, IMO, it can stay there.

ok

(one reason I don't like IRC/chat systems that are throw away things not useful except on the moment, and why I'm really pissed off that google killed the usenet archive)

I'm a bit young to remember the IRC and usenet :D Though I caught them, it was only for 2 years and never used them, since better alternatives already existed at that time.

what I meant was to keep the link to this chat and remove those 3 comments, which only in my opinion detracted from the conversation on your solution.

@StéphaneChazelas You also know a lot of sed. Do you mind if I ask you to spot the mistake in my answer unix.stackexchange.com/a/524003/226955