Consider a form of "Here Documents" to utilize the entire source line
regardless of how long it is.
This type of redirection instructs the shell to read input from the
current source until a line containing only word (with no trailing
blanks) is seen. All of the lines read up to that point are then used as
the standard input for a command.
The format of here-documents is:
No parameter expansion, command substitution, arithmetic expansion, or
filename expansion is performed on word. If any characters in word are
quoted, the delimiter is the result of quote removal on word, and the
lines in the here-document are not expanded. If word is unquoted, all
lines of the here-document are subjected to parameter expansion, command
substitution, and arithmetic expansion. In the latter case, the
character sequence \newline is ignored, and '\' must be used to quote
the characters '\', '$', and '`'.
If the redirection operator is '<<-', then all leading tab characters
are stripped from input lines and the line containing delimiter. This
allows here-documents within shell scripts to be indented in a natural
From: WDSCI-L [mailto:wdsci-l-bounces@xxxxxxxxxxxx] On Behalf Of Taryn
Sent: Wednesday, June 11, 2014 12:10 PM
Subject: [WDSCI-L] Feedback regarding the automatic SQL Formatter
The development team is looking to improve some functionality with the
SQL automatic formatter and we are seeking your feedback to give us some
guidance. Some of you may have experienced the frustration of pushing
embedded SQL code beyond column 80 while the automatic formatting
preference is turned on. Once the cursor is moved to another line, the
formatter will re-format the SQL statement but leave behind any code
pushed beyond column 80, since anything after this is generally
considered a comment and should be ignored.
We are proposing a solution to have another preference to turn on with
the SQL formatter that will allow SQL that goes beyond column 80 to be
considered part of the statement and not a comment. This will prevent
the formatter from ignoring any code that may get pushed out during a
reformat of the statement.
What we would like to know is how many of you use the space beyond
80 to write the comments for SQL statements, versus including it
directly in the code (ie: using '//' or '/*' to comment). Also, would
this solution help those who use automatic SQL formatting? If this
solution helps, we would appreciate any recommendations on what the new
preference should be named in order to make its intention obvious to the
Software Developer for Rational Developer for i
This is the Rational Developer for IBM i / Websphere Development Studio
Client for System i & iSeries (WDSCI-L) mailing list To post a message
email: WDSCI-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
As an Amazon Associate we earn from qualifying purchases.