Is there a way to make this look a little better?
conn.exec 'select attr1, attr2, attr3, attr4, attr5, attr6, attr7 ' + 'from table1, table2, table3, etc, etc, etc, etc, etc, ' + 'where etc etc etc etc etc etc etc etc etc etc etc etc etc' Like, is there a way to imply concatenation?
There are pieces to this answer that helped me get what I needed (easy multi-line concatenation WITHOUT extra whitespace), but since none of the actual answers had it, I'm compiling them here:
str = 'this is a multi-line string'\ ' using implicit concatenation'\ ' to prevent spare \n\'s' => "this is a multi-line string using implicit concatenation to eliminate spare \\n's" As a bonus, here's a version using funny HEREDOC syntax (via this link):
p <<END_SQL.gsub(/\s+/, " ").strip SELECT * FROM users ORDER BY users.id DESC END_SQL # >> "SELECT * FROM users ORDER BY users.id DESC" The latter would mostly be for situations that required more flexibility in the processing. I personally don't like it, it puts the processing in a weird place w.r.t. the string (i.e., in front of it, but using instance methods that usually come afterward), but it's there. Note that if you are indenting the last END_SQL identifier (which is common, since this is probably inside a function or module), you will need to use the hyphenated syntax (that is, p <<-END_SQL instead of p <<END_SQL). Otherwise, the indenting whitespace causes the identifier to be interpreted as a continuation of the string.
This doesn't save much typing, but it looks nicer than using + signs, to me.
Also (I say in an edit, several years later), if you're using Ruby 2.3+, the operator <<~ is also available, which removes extra indentation from the final string. You should be able to remove the .gsub invocation, in that case (although it might depend on both the starting indentation and your final needs).
EDIT: Adding one more:
p %{ SELECT * FROM users ORDER BY users.id DESC }.gsub(/\s+/, " ").strip # >> "SELECT * FROM users ORDER BY users.id DESC" 
<<~ to the answer would be nice, ended up researching that from there. Personnally, I use <<~MSG.strip ... MSG which also strips the last \n.
In ruby 2.0 you can now just use %
For example:
SQL = %{ SELECT user, name FROM users WHERE users.id = #{var} LIMIT #{var2} } 
squish on the output should be helpful.Yes, if you don't mind the extra newlines being inserted:
conn.exec 'select attr1, attr2, attr3, attr4, attr5, attr6, attr7 from table1, table2, table3, etc, etc, etc, etc, etc, where etc etc etc etc etc etc etc etc etc etc etc etc etc' Alternatively you can use a heredoc:
conn.exec <<-eos select attr1, attr2, attr3, attr4, attr5, attr6, attr7 from table1, table2, table3, etc, etc, etc, etc, etc, where etc etc etc etc etc etc etc etc etc etc etc etc etc eos 
%Q(...)
%(...)
This question made me go off a rabbit hole to understand how HEREDOC works. Excuse me if the answer became too long.
The squiggly HEREDOC <<~ is what you are looking for when you want to define a multi-line string with newlines and proper indentation (available since Ruby 2.3):
conn.exec <<~EOS select attr1, attr2, attr3, attr4, attr5, attr6, attr7 from table1, table2, table3, etc, etc, etc, etc, etc where etc etc etc etc etc etc etc etc etc etc etc etc etc EOS # -> "select...\nfrom...\nwhere..." If proper indentation is not a concern, then single and double quotes can span multiple lines in Ruby:
conn.exec "select attr1, attr2, attr3, attr4, attr5, attr6, attr7 from table1, table2, table3, etc, etc, etc, etc, etc, where etc etc etc etc etc etc etc etc etc etc etc etc etc" # -> "select...\n from...\n where..." If single or double quotes are cumbersome because that would need lots of escaping, then the percent string literal notation % is the most flexible solution:
conn.exec %(select attr1, attr2, attr3, attr4, attr5, attr6, attr7 from table1, table2, table3, etc, etc, etc, etc, etc where (ProductLine = 'R' OR ProductLine = "S") AND Country = "...") # -> "select...\n from...\n where..." If the aim is to avoid the newlines (which both the squiggly HEREDOC, quotes and the percent string literal will cause), then a line continuation can be used by putting a backslash \ as the last non-whitespace character in a line. This will continue the line and will cause Ruby to concatenate the Strings back to back (watch out for those spaces inside the quoted string):
conn.exec 'select attr1, attr2, attr3, attr4, attr5, attr6, attr7 ' \ 'from table1, table2, table3, etc, etc, etc, etc, etc, ' \ 'where etc etc etc etc etc etc etc etc etc etc etc etc etc' # -> "select...from...where..." If you use Rails, then String.squish will strip the string of leading and trailing space and collapse all consecutive whitespaces (newlines, tabs, and all) into a single space:
conn.exec "select attr1, attr2, attr3, attr4, attr5, attr6, attr7 from table1, table2, table3, etc, etc, etc, etc, etc, where etc etc etc etc etc etc etc etc etc etc etc etc etc".squish # -> "select...attr7 from...etc, where..." More details:
The Here Document Notation for Strings is a way to designate long blocks of text inline in code. It is started by << followed by a user-defined String (the End of String terminator). All following lines are concatenated until the End of String terminator is found at the very beginning of a line:
puts <<HEREDOC Text Text Text Text Bla Bla HEREDOC # -> "Text Text Text Text\nBlaBla" The End of String terminator can be chosen freely, but it is common to use something like "EOS" (End of String) or something that matches the domain of the String such as "SQL".
HEREDOC supports interpolation by default or when the EOS terminator is double quoted:
price = 10 print <<"EOS" # comments can be put here 1.) The price is #{price}. EOS # -> "1.) The price is 10." Interpolation can be disabled if the EOS terminator is single quoted:
print <<'EOS' # Disabled interpolation 3.) The price is #{price}. EOS # -> "3.) The price is #{price}." One important restriction of the <<HEREDOC is that the End of String terminator needs to be at the beginning of the line:
puts <<EOS def foo print "foo" end EOS EOS #-> "....def foo\n......print "foo"\n....end\n..EOS" To get around this, the <<- syntax was created. It allows the EOS terminator to be indented to make the code look nicer. The lines between the <<- and EOS terminator are still used in their full extend including all indentation:
def printExample puts <<-EOS # Use <<- to indent End of String terminator def foo print "foo" end EOS end # -> "....def foo\n......print "foo"\n....end" Since Ruby 2.3, we now have the squiggly HEREDOC <<~ which removes leading whitespace:
puts <<~EOS # Use the squiggly HEREDOC <<~ to remove leading whitespace (since Ruby 2.3!) def foo print "foo" end EOS # -> "def foo\n..print "foo"\nend" Empty lines and lines which only contains tabs and space are ignored by <<~
puts <<~EOS.inspect Hello World! EOS #-> "Hello\n..World!" If both tabs and spaces are used, tabs are considered as equal to 8 spaces. If the least-indented line is in the middle of a tab, this tab is not removed.
puts <<~EOS.inspect <tab>One Tab <space><space>Two Spaces EOS # -> "\tOne Tab\nTwoSpaces" HEREDOC can do some crazy stuff such as executing commands using backticks:
puts <<`EOC` echo #{price} echo #{price * 2} EOC HEREDOC String definitions can be "stacked", which means that the first EOS terminator (EOSFOO below) will end the first string and start the second (EOSBAR below):
print <<EOSFOO, <<EOSBAR # you can stack them I said foo. EOSFOO I said bar. EOSBAR I don't think anybody would ever use it as such, but the <<EOS is really just a string literal and can be put whereever a string can normally be put:
def func(a,b,c) puts a puts b puts c end func(<<THIS, 23, <<THAT) Here's a line or two. THIS and here's another. THAT If you don't have Ruby 2.3, but Rails >= 3.0 then you can use String.strip_heredoc which does the same as <<~
# File activesupport/lib/active_support/core_ext/string/strip.rb, line 22 class String def strip_heredoc gsub(/^#{scan(/^[ \t]*(?=\S)/).min}/, "".freeze) end end puts <<-USAGE.strip_heredoc # If no Ruby 2.3, but Rails >= 3.0 This command does such and such. Supported options are: -h This message ... USAGE If you see errors when Ruby parses your file, then it is most likely that you either have extra leading or trailing spaces with a HEREDOC or extra trailing spaces with a squiggly HEREDOC. For example:
What you see:
database_yml = <<~EOS production: database: #{fetch(:user)} adapter: postgresql pool: 5 timeout: 5000 EOS What Ruby tells you:
SyntaxError: .../sample.rb:xx: can't find string "EOS" anywhere before EOF ...sample.rb:xx: syntax error, unexpected end-of-input, expecting `end' What is at fault:
Spot the extra spaces after the terminating EOS.
See RubyDoc for how to use the percentage string literals. Percentage string literals start with a percentage sign % followed either an opening parenthesis or any non-alphanumeric character. Then you put your string and end the string literal with the associated closing parenthesis symbol or the non-alphanumeric character.
Thus you could use %(...), %[...], %{...} or e.g. %+...+.
No matter which symbol or parentheses (round, square, curly) the result is always the same: Just a string literal.
You simply chose the terminators that are the least likely to be used in the string inside, reducing the need to do escaping. For example, in SPARQL queries {} and () and [] are all used, so it might make sense to use %$...$. In SQL, [] and () are common, thus %{} could be a good pick.
Last, to get the answer to the original question "Is there a way to imply concatenation?" answered: Ruby always implies concatenation if two strings (single and double quoted) are found back to back:
puts "select..." 'from table...' "where..." # -> "select...from table...where..." The caveat is that this does not work across line-breaks, because Ruby is interpreting an end of statement and the consequitive line of just strings alone on a line doesn't do anything.
%{}, %(), %[] strings are processed. You simply chose the terminators that are the least likely to be used in the string inside, removing (or almost eliminating) the need to do any escaping. For example, in SPARQL queries {} and () are common, and [] could be used for lists, it makes sense to use %$$. In SQL, [] and () are common, %{} could be a good pick (except for T-SQL, maybe). I also like to pick chars that one needs to escape in Bash, \$ looks natural.There are multiple syntaxes for multi-line strings as you've already read. My favorite is Perl-style:
conn.exec %q{select attr1, attr2, attr3, attr4, attr5, attr6, attr7 from table1, table2, table3, etc, etc, etc, etc, etc, where etc etc etc etc etc etc etc etc etc etc etc etc etc} The multi-line string starts with %q, followed by a {, [ or (, and then terminated by the corresponding reversed character. %q does not allow interpolation; %Q does so you can write things like this:
conn.exec %Q{select attr1, attr2, attr3, attr4, attr5, attr6, attr7 from #{table_names}, where etc etc etc etc etc etc etc etc etc etc etc etc etc} I actually have no idea how these kinds of multi-line strings are called so let's just call them Perl multilines.
Note however that whether you use Perl multilines or heredocs as Mark and Peter have suggested, you'll end up with potentially unnecessary whitespaces. Both in my examples and their examples, the "from" and "where" lines contain leading whitespaces because of their indentation in the code. If this whitespace is not desired then you must use concatenated strings as you are doing now.
%q family will include the newlines which is not equivilent to the original code.Sometimes is worth to remove new line characters \n like:
conn.exec <<-eos.squish select attr1, attr2, attr3, attr4, attr5, attr6, attr7 from table1, table2, table3, etc, etc, etc, etc, etc, where etc etc etc etc etc etc etc etc etc etc etc etc etc eos 
You can also use double quotes
x = """ this is a multiline string """ 2.3.3 :012 > x => "\nthis is\na multiline\nstring\n" If needed to remove line breaks "\n" use backslash "\" at the end of each line
"" + "double quotes with some content" + "".
"x" looks better and works faster than """x""" (which is basically the same as ""+"x"+"") or """""x""""" (which is the same as "" + "" + "x" + "" + ""). It's Ruby, not Python, where you use """ instead of " when you need a multi-line string.Other options:
#multi line string multiline_string = <<EOM This is a very long string that contains interpolation like #{4 + 5} \n\n EOM puts multiline_string #another option for multiline string message = <<-EOF asdfasdfsador #{2+2} this month. asdfadsfasdfadsfad. EOF puts message 
<<EOM to <<-EOM, no?
<<-EOF example. My guess is that either way works.Recently with the new features in Ruby 2.3 the new squiggly HEREDOC will let you write our multiline strings in a nice manner with a minimal change so using this combined with the .squish (if you are using rails) will let you write multiline in a nice way! in case of just using ruby, you can do a <<~SQL.split.join(" ") which is almost the same
[1] pry(main)> <<~SQL.squish [1] pry(main)* select attr1, attr2, attr3, attr4, attr5, attr6, attr7 [1] pry(main)* from table1, table2, table3, etc, etc, etc, etc, etc, [1] pry(main)* where etc etc etc etc etc etc etc etc etc etc etc etc etc [1] pry(main)* SQL => "select attr1, attr2, attr3, attr4, attr5, attr6, attr7 from table1, table2, table3, etc, etc, etc, etc, etc, where etc etc etc etc etc etc etc etc etc etc etc etc etc" ref: https://infinum.co/the-capsized-eight/multiline-strings-ruby-2-3-0-the-squiggly-heredoc
conn.exec = <<eos select attr1, attr2, attr3, attr4, attr5, attr6, attr7 from table1, table2, table3, etc, etc, etc, etc, etc, where etc etc etc etc etc etc etc etc etc etc etc etc etc eos To avoid closing the parentheses for each line you can simply use double quotes with a backslash to escape the newline:
"select attr1, attr2, attr3, attr4, attr5, attr6, attr7 \ from table1, table2, table3, etc, etc, etc, etc, etc, \ where etc etc etc etc etc etc etc etc etc etc etc etc etc" 
<<~TEXT Hi #{user.name}, Thanks for raising the flag, we're always happy to help you. Your issue will be resolved within 2 hours. Please be patient! Thanks again, Team #{user.organization.name} TEXT Theres a difference in <<-TEXT and <<~TEXT, former retains the spacing inside block and latter doesn't.
There are other options as well. Like concatenation etc. but this one makes more sense in general.
If I am wrong here, let me know how...
conn.exec 'select attr1, attr2, attr3, attr4, attr5, attr6, attr7 ' << 'from table1, table2, table3, etc, etc, etc, etc, etc, ' << 'where etc etc etc etc etc etc etc etc etc etc etc etc etc' << is the concatenation operator for strings
+ is the regular concatenation operator, << is the in-place append operator. Using side effects on a literal happens to work here (the first string is modified twice and returned) but IMHO it's weird and makes me do a double-take, where + would be perfectly clear. But maybe I'm just new to Ruby...
frozen_string_literal is enabledIf you do mind extra spaces and newlines, you can use
conn.exec %w{select attr1, attr2, attr3, attr4, attr5, attr6, attr7 from table1, table2, table3, etc, etc, etc, etc, etc, where etc etc etc etc etc etc etc etc etc etc etc etc etc} * ' ' (use %W for interpolated strings)
conn.exec [ "select attr1, attr2, attr3, ...", "from table1, table2, table3, ...", "where ..." ].join(' ') This suggestion has the advantage over here-documents and long strings that auto-indenters can indent each part of the string appropriately. But it comes at an efficiency cost.
Like you, I was also looking for a solution which does not include newlines. (While they may be safe in SQL, they're not safe in my case and I have a large block of text to deal with)
This is arguably just as ugly, but you can backslash-escape newlines in a heredoc to omit them from the resulting string:
conn.exec <<~END_OF_INPUT select attr1, attr2, attr3, attr4, attr5, attr6, attr7 \ from table1, table2, table3, etc, etc, etc, etc, etc, \ where etc etc etc etc etc etc etc etc etc etc etc etc etc END_OF_INPUT Note that you cannot due this without interpolation (I.E. <<~'END_OF_INPUT') so be careful. #{expressions} will be evaluated here, whereas they will not in your original code. A. Wilson's answer may be better for that reason.
