Solved scratching my head for a while with less ...

For some period of time, I don't want to admit how long, less was first executing files and then actually opening them up.

Long story short, I saw my configuration for source highlight was clobbered, instead of:

Code:
export LESSOPEN="| /usr/local/bin/src-hilite-lesspipe.sh %s"
export LESS=" -R "

It was:
Code:
export LESSOPEN="| %s"
export LESS=" -R "

I was able to trace the problem back to a large refactor I did for all of my 'apps' programming in shell :). I moved from a separate git repository into a monolith repository so I could more easily share libraries across these 'apps' when they're 'compiled'. At the same time, I renamed configuration keys and essentially, when this was set, the configuration key it was pointing to didn't exist.

This perhaps nothing to do with less, but more rather how users (myself) can easily shoot themselves in the foot quickly and possibly do damage unintentionally.

Well, at least now again, I can now view color-coded source code without less trying to execute it first.
 
Have you tried stringing the commands together a little differently?

Like:

Code:
% cat myfile.sh | less

I'm sure that this way, you can still view color-coded source code without /bin/less trying to execute it first.

Sometimes complicated terminal config can result in unintended side effects. Keeping things simple, and having a clean separation is generally a good strategy.
 
I hear you, though as the saying goes, "You can lead a horse to the water, but you cannot force it to drink". That might apply to me in this case.

Yes, I am battling duplication of effort and complexity. I'm looking for the right balance of complexity and expression, I'm not sure if it is a futile exercise or an exercise in seeing how long the hair will last on my head.
 
Yes, I use that as well. I suppose the intention of this post was making fun of my mistakes as it was a bit stressful for me, sometimes I wonder, have I been compromised :).
 
Back
Top