Author Topic: A couple of BourneShell issues  (Read 283 times)


  • Junior Community Member
  • Posts: 5
  • Hero Points: 3
A couple of BourneShell issues
« on: July 29, 2018, 01:25:14 pm »
SlickEdit Pro 2018 (v23.0.0.2 64-bit)
Emulation: CUA
OS: Windows 10 x64

I'm not sure these are new for 23.0.0, I just ran into them last week. 

All of these were done from a vs -sc c:\tmp clean config.

1. Comment lines don't auto-extend or split.  I see that all of the Comment Editing options are disabled in Tools > Options > Languages > Scripting Languages > Bourne Shell > Comments.  Is this intentional?  If so, is there something about Bash comments that make them harder to extend/split than, say, Perl comments?  (Also, unlike the handful of other languages I checked, Bourne Shell's 'Comment block' and 'Comment line' characters did not come up pre-populated in Tools > Options > Languages > Scripting Languages > Bourne Shell > Comments with a clean config.)

2. Generic heredocs (like cat<<EOF) don't get the embedded language background color.  Heredocs with a language tag (like cat<<sqlEOF) look fine, complete with background and syntax coloring.  I did try checking the 'Here document (UNIX Shells/Perl)' box in Tools > Options > Languages > Scripting Languages > Bourne Shell > Color Coding, but that returned an error message (Color coding profile 'Bourne Shell': Invalid type 'here_document') when I hit OK.




  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 4669
  • Hero Points: 375
Re: A couple of BourneShell issues
« Reply #1 on: August 02, 2018, 04:16:13 pm »
Thanks for the post.

1. This limitation is due to the fact that the # token is not always a line comment (ex. "foo#not-comment-here"). It's possible but it can't be handled like other languages the color coding information gets scanned for non-regex line comments. In the case of bourne shell, this line comment is a regex and not simply # which means the code currently doesn't even know what starts the line comment that you're splitting. If you changed the color coding profile so that # anywhere (not a regex) starts a line comment, then it would work.

2. Generic heredocs (like cat<EOF) since v22 are colored as non-embedded string color and not embedded color. This type of change was applied to many similar situations for all languages in v22. Embedded color was previously used due to limitations in the old color coding engine. The heredoc is really just another syntax for a string. When a language is matched then embedded color makes sense because you actually changed languages.