In the wide picture you show:
...cd maldetect-* &&␠|<-window boundary
(the char before the vertical bar is HTML ␠
or unicode char U+2420(symbol for space).
That space SHOULD (HAS) to be there. If the window boundary wasn't there,
then the line would be:
...cd maldetect-* && bash ./install.sh
If you didn't have the space, then && wouldn't have a space
between it and the start of the 'bash' word -- which shouldn't hurt if you are running in bash, BUT that's just 1 example .. i.e. normally you would have a space between the double ampersand and the space.
If your spaces should be there, what might be causing your problems... hmmmm....
ARG! You are pasting this "into"... bash... Uh oh...
If you are pasting into bash, bash is 'buggy' (a matter of opinion) for pasting due to autocomplete changes made a few years ago. If you have any 'TAB's in your pasted text (yup, indenting), it will invoke bash's "autocomplete" function (I have complained about this but I was told that no one pastes text into bash... cough, cough) (complain on the 'email@example.com list' though I doubt it will be fixed anytime soon). When it invokes the autocomplete -- many time it will swallow the next character of your pasted text because it asks a question:
> ls <'complete-key' pressed>
Display all 199 possibilities? (y or n)
As a rule, this corrupts pasted text. This used to not be a problem for me, anyway, as my tabs are usually on blank-lines (because they are indenting code). It used to be the case there was an option to ignore code-completion presses on a blank line (@ start of line or when only blanks precede where it is pressed). This was changed to only ignore the completion char on empty command-lines (not an empty tty-line). Pasting multiple commmands into input usually are seen as bash as some sort of continued command -- NOT an empty command line. Needless to say, this causes alot of problems.
An imperfect solution for me was to remap the code-completion key from TAB
to Backquote ("
") (above tilde key). (same bug occurs if you have in your text, but for me, I use that alot less often than TAB). It's set in your home directory's '.inputrc' file which controls how 'readline' (used by bash to read lines, allow edit, etc), behaves. In particular, a section in my ".inputrc" has bash-specific config options:
# use backquote as completion (yes, that's shift-'~')
# not ideal, but quickest "hack" to get mostly
# transparent pasting (backquote isn't used nearly as often as TAB)
Alternatives: 1) convert all your tabs to spaces before pasting, so TAB won't trigger command completion. 2) always write the text to a file and
source (.) the file or make it executable and add '#!/bin/bash' on 1st line to make it a shell script.
Theoretically you should also be able to turn command completion off, but I use it too much, so have never bothered to try.
What I usually do now, is I edit the script in 1 window (usually gvim), and in the window where I started gvim, I run successive iterations of the script -- thus avoiding 'pasting'. Certainly wasn't my 1st choice, but bash's corrupting input by swallowing things after a complete-key have pushed me in that direction.
Note, if you report this as a bug, be prepared to offer a solution! ;-) This is the rub:
> ls \<carriage return>
>> [here people want to be able to hit 'TAB' and get an autocomplete of
of the files in the current directory. It looks like an empty line,
but it is a really a continued command line from the previous line.
Same thing happens when you paste commands into bash... some will have tabs where you don't want them...
(P.s. Hope this helps and I didn't completely go off into left field, but when you mentioned 'pasting' and it looks like bash-script...and you mention using tabs (that get pasted in, as well), sounded like the exact same problem I ran into.
Using backquote as a complete key is a bit awkward at times, but, too often will have tabs in pasted text...oh well)