Syntax highlighting of less
, works just fine on most *nix systems.
apt install source-highlight
export LESSOPEN="| /usr/share/source-highlight/src-hilite-lesspipe.sh %s"
export LESS=' -R '
On Fedora/RedHat based distros use /usr/bin/src-hilite-lesspipe.sh
instead.
Even on Cygwin you can do it with the minor adjustment of the shell script path and installing with apt-cyg
instead of apt
.
However, using this drastically slows down browsing of large files. I suggest to use alias
in such a way to only implement the LESSOPEN
export above when needed, like this:
alias lessh='LESSOPEN="| /usr/bin/src-hilite-lesspipe.sh %s" less -M '
where the -M
flag is convenient to also show filename and line number.
Also remember to copy the script into your bin path:
cp /usr/share/source-highlight/src-hilite-lesspipe.sh /usr/bin/src-hilite-lesspipe.sh
UPDATE: 2019-07-24
Apparently, on more recent Cygwin installs, you have the following files in your path:
source-highlight.exe
source-highlight-esc.sh
source-highlight-settings.exe
So now you also need to execute the source-highlight-settings.exe
that will add the configuration file:
$HOME/.source-highlight/source-highlight.conf
.
The {}
just groups commands together in the current shell, while ()
starts a new subshell. However, what you're doing is putting the grouped commands into the background, which is indeed a new process; if it was in the current process, it could not possibly be backgrounded. It's easier, IMHO, to see this kind of thing with strace:
sauer@humpy:~$ strace -f -etrace=process bash -c '{ sleep 10; echo "Sleeping process", $BASHPID, $BASH_SUBSHELL; } & echo $BASHPID;' > /tmp/file
execve("/bin/bash", ["bash", "-c", "{ sleep 10; echo \"Sleeping proce"...], [/* 20 vars */]) = 0
arch_prctl(ARCH_SET_FS, 0x7f15a90da700) = 0
clone(Process 25347 attached
child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f15a90da9d0) = 25347
[pid 25346] exit_group(0) = ?
clone(Process 25348 attached (waiting for parent)
Process 25348 resumed (parent 25347 ready)
child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f15a90da9d0) = 25348
[pid 25348] execve("/bin/sleep", ["sleep", "10"], [/* 20 vars */] <unfinished ...>
[pid 25347] wait4(-1, Process 25347 suspended
<unfinished ...>
[pid 25348] <... execve resumed> ) = 0
[pid 25348] arch_prctl(ARCH_SET_FS, 0x7f922ad16700) = 0
[pid 25348] exit_group(0) = ?
Process 25347 resumed
Process 25348 detached
<... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 25348
--- SIGCHLD (Child exited) @ 0 (0) ---
wait4(-1, 0x7fffaa432ad8, WNOHANG, NULL) = -1 ECHILD (No child processes)
exit_group(0) = ?
Process 25347 detached
sauer@humpy:~$ cat /tmp/file
25346
Sleeping process, 25347, 1
Note that the bash command starts, then it creates a new child with clone()
. Using the -f option to strace means it also follows child processes, showing yet another fork (well, "clone") when it runs sleep. If you leave the -f off, you see just the one clone call when it creates the backgrounded process:
sauer@humpy:~$ strace -etrace=clone bash -c '{ sleep 10; echo "Sleeping process", $BASHPID, $BASH_SUBSHELL; } & echo $BASHPID;' > /tmp/file
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f2bdd5399d0) = 26394
sauer@humpy:~$ strace -etrace=process bash -c '{ sleep 10; echo "Sleeping process", $BASHPID, $BASH_SUBSHELL; } & echo $BASHPID;' > /dev/null
execve("/bin/bash", ["bash", "-c", "{ sleep 10; echo \"Sleeping proce"...], [/* 20 vars */]) = 0
arch_prctl(ARCH_SET_FS, 0x7fd01ae86700) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fd01ae869d0) = 26706
exit_group(0) = ?
If you really just want to know how often you're creating new processes, you can simplify that even further by only watching for fork and clone calls:
sauer@humpy:~$ strace -etrace=fork,clone bash -c '{ sleep 10; echo "Sleeping process", $BASHPID, $BASH_SUBSHELL; } & echo $BASHPID;' > /dev/null
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f467fa769d0) = 27025
Best Answer
I don't think this exists. It would be useful, but hard to implement by standard means of syntax parsing used in editors. From the parsing point of view, there are many keywords and special symbols that would have to be analysed to determine a block of code that belongs to a subshell.
But I'd be happy to see I'm wrong and someone has put the effort needed to create such configurations.