*** missing separator despite using tabs - makefile

Asking this question is my last resort. I try to run "make all" and I get the error
Makefile:457: *** missing separator. Stop.
on the the line with cloc (second line).
linecount:
cloc --read-lang-def=$(PROJECT).cloc \
src/$(PROJECT) include/$(PROJECT) tools examples \
python matlab
I changed spaces to tabs both on that line and inside the file $(PROJECT).cloc. However, the error persists. And it only appears on that line. I am at a loss.

Use vim or vi to open makefile then write :set list it will show you all the spaces and tabs. Tabs are ^I and line endings are ^$ . Make sure your indentation is always with tabs instead of spaces or even 4 spaces. 4 spaces doesn't make a tab in makefile you should use tabs for indentation. You can make this with other editors as well.

You can do the same thing as in Alperen's answer with nano by opening the makefile and using the key combination alt+shift+p to enable whitespace display where tabs will be represented by a > character and spaces by a . character. This will indicate what make is 'seeing' at the beginning of that line, it may not be a tab character despite what it may seem.

Related

Weird txt behavior

I have a centos server. I cloned a GitHub repository. And I have .txt file in that repository which contains 1 line. For some reason it does that:
[root#0-0-0-0 Some]# cat some.txt
some text[root#0-0-0-0 Some]#
And also while read i; do echo "$i"; done < some.txt don't see that line. What could cause that? And how to avoid it. If I edit it with vim adding a new line and then deleting that new line (so it still contains only one line) it starts to work properly.
The text file has no newline character at the end of it. Some programs will treat it as a valid text file whose last line doesn't happen to end in a newline. Others (apparently including bash's built-in read command, at least by default) will treat it as invalid, and perhaps ignore the last line (which isn't considered a "line" because it's not marked as one).
vim's default behavior is to quietly add a newline to the end of a file if you modify and save it.
You can add a newline to a file that lacks one by editing it with vim (or another editor that behaves similarly), or by adding it from the shell:
echo '' >> some.txt
In general, it's a good idea to ensure that text files end in a newline character in the first place, at least if they're intended to be used on UNIX-like systems.

Prevent Git Gui from highlighting trailing spaces

Git Gui shows spaces at the end of line highlighted with red; how can I turn off this feature?
Apparently (see comments) Git Gui uses the same control knob here as plain command-line git, namely the core.whitespace setting, as described in the git config documentation:
core.whitespace
A comma separated list of common whitespace problems to notice. git diff will use color.diff.whitespace to highlight them, and git apply --whitespace=error will consider them as errors. You can prefix - to disable any of them (e.g. -trailing-space):
blank-at-eol treats trailing whitespaces at the end of the line as an error (enabled by default).
space-before-tab treats a space character that appears immediately before a tab character in the initial indent part of the line as an error (enabled by default).
indent-with-non-tab treats a line that is indented with space characters instead of the equivalent tabs as an error (not enabled by default).
tab-in-indent treats a tab character in the initial indent part of the line as an error (not enabled by default).
blank-at-eof treats blank lines added at the end of file as an error (enabled by default).
trailing-space is a short-hand to cover both blank-at-eol and blank-at-eof.
cr-at-eol treats a carriage-return at the end of line as part of the line terminator, i.e. with it, trailing-space does not trigger if the character before such a carriage-return is not a whitespace (not enabled by default).
tabwidth=<n> tells how many character positions a tab occupies; this is relevant for indent-with-non-tab and when Git fixes tab-in-indent errors. The default tab width is 8. Allowed values are 1 to 63.
(I'm not sure how Git Gui allows you to modify the config, or whether you must do that from a command line. Presumably you want -trailing-space in this case, or maybe just -blank-at-eol.)

git bash on windows: interactive mode doesn't work

Well, the problem is any command involving manipulations with patches refuses to work in the following manner:
<stdin>:16: trailing whitespace.
<stdin>:17: trailing whitespace.
<stdin>:18: trailing whitespace.
<stdin>:19: trailing whitespace.
<stdin>:20: trailing whitespace.
warning: recount: unexpected line:
fatal: corrupt patch at line 101
(As a result?) Interactive mode doesn't work.
Tried to tweak core.whitespace with no success.
Please help me to resolve this annoying issue.
This message usually comes from the pre-commit hook when its checking for non-ascii content.
The sample pre-commit hook may be doing a check for trailing whitespace.
To disable it, look in .git/hooks and make sure the files there are not executable.
###git-stripspace
Read
https://www.kernel.org/pub/software/scm/git/docs/git-stripspace.html

Putty: copy & paste -> preserve blanks

we want to switch to Putty at work, but we have one big problem: in error situations we have to copy some lines from our logfile (using less/vi and mouse copy & paste). These lines can be 32 KB long and contain several blanks, the blanks need to be preserved. Unfortunately, if the copied content is wrapped because it doesn't fit in one line in the window, Putty seems to replace the trailing blanks with a newline character.
e.g. if we have the line (with trailing spaces that need to be preserved -> you see the trailing spaces if you select the example):
LINE START, WINDOW IS 80 CHARACTERS WIDTH, BUT LINE IS 32KB
SO LINE IS WRAPPED IN THE PUTTY WINDOW
THE TRAILING SPACES NEED TO BE PRESERVED....
BUT USING PUTTYS COPY & PASTE, PUTTY REPLACES SPACE CHARACTERS BY NEWLINE
...LINE END
and we copy & paste, we get (select second example):
LINE START, WINDOW IS 80 CHARACTERS WIDTH, BUT LINE IS 32KB
SO LINE IS WRAPPED IN THE PUTTY WINDOW
THE TRAILING SPACES NEED TO BE PRESERVED....
BUT USING PUTTYS COPY & PASTE, PUTTY REPLACES SPACE CHARACTERS BY NEWLINE
...LINE END
Putty cuts the trailing spaces and inserts a newline character. Can this behaviour be configured/changed in Putty?
Thank you,
Christian
I have used non-breaking spaces to retain trailing whitespace when copying/pasting from PuTTY. My application was ssh-ing into a linux box and copying/pasting some code using the Bourne shell, so I don't know how widely this will work in other environments.
To insert a non-breaking space, hold the Alt key and type 255, then release the Alt key. The following example can be used for testing. For some reason, the code doesn't retain the non-breaking space when I copy/paste directly from this webpage, so you will need to test it this way:
a. Copy/paste the code below into notepad
b. Delete the space in blank=" "
c. Insert a non-breaking space with Alt+255
d. Copy/paste the code into PuTTY
e. Copy/paste the output back into notepad to view results
CODE
# non-breaking space, Alt+255
blank=" "
# regular space
space=" "
echo "
blank:$blank
space:$space
"
Which outputs a trailing space for the $blank var, but not for the $space var.
OUTPUT
blank:
space:
I'm not sure that Putty can do it but in my case (putty working on redhat open client) I converted source files to unix format (dos2unix command).
Now pasting works fine.

How does one align code (braces, parens etc) in vi?

How do you prettify / align / format code in vi? What is the command?
I have pasted in a hunk of code and I need to have it all formatted/aligned... obviously I am a vi neophyte.
x
These commands in my answer work in vim. Most people who think they're using vi are using vim. To find out if your 'vi' is really 'vim', open vi and type :version -- if it's vim, it will say so. Otherwise you might just see a version number without the name of the program. Also, when you open vim for the first time you will usually see a splash screen of some sort that says "VIM - VI iMproved"...
Automatic Indentation
To turn auto-indentation on, make sure vim knows the file type you're editing (it usually automatically detects this from the file name extension, but might not figure it out with some file types). You can tell it the filetype using the menus for syntax highlighting. Then, do this:
:filetype indent on
You can disable auto-indentation with
:filetype indent off
Automatically adjusting/correcting indentation
In general, ={motion} will align code to an indentation level.
== align the current line
=i{ align the inner block
=% align to the matching parenthesis/bracket under the cursor
=14j or 14== align the next 14 lines
=G align to the end of the file
vG= same thing, align to the end of the
file (but using visual mode)
vjjj= align four lines (using visual mode)
Manual indentation
If vim is not guessing the indentation level correctly, there are two ways to change it:
If you are in normal mode (where everything is a command), do << to shift a line left, or >> to shift it right by one tab. You can do this with several lines by using the same movement commands I showed above (eg, >i{ indents the current inner code block).
If you are in insert mode, you can indent the line further (without moving the cursor) by doing a Ctrl-T, or un-indent one tab with Ctrl-D
Aligning equals signs, etc
If you want to align equals signs in a list of declarations, you should consider using this vim script: http://www.vim.org/scripts/script.php?script_id=294
Adjusting indentation/tab sizes
If you want vim to use spaces instead of tabs when it indents, run this command (or consider adding it to your vimrc file)
:set expandtab
To set how many spaces equal a tab, I usually do this:
:set expandtab softtabstop=3 tabstop=3 shiftwidth=3
tabstop - how many columns a tab counts for (affects display of existing tab characters)
shiftwidth - controls reindentation size with << and >>, among other commands.
softtabstop - how much space to insert when you press the tab key
expandtab - expand tab keys to spaces
But if you have to work with different amounts of tabs a lot, you could also use this function and keybinding:
function! Ktabs(tabsize)
execute "set softtabstop=" . a:tabsize . " tabstop=" . a:tabsize . " expandtab shiftwidth=" . a:tabsize
"set softtabstop=a:tabsize tabstop=a:tabsize expandtab shiftwidth=a:tabsize
endfunction
noremap <leader><Tab> :call Ktabs(3)<Left>
If you are editing a file with a mix of tabs and spaces, you may want to use this command after setting tab size:
:retab
={motion}
:h =
P.S. You shouldn't use vi if vim is available.
If manually adjusting indents I will open a visual block with V on the first or last line I want to re-indent, move to the brace containing the block, goto the other brace with % then shift the line with > or <
If indents are off by a lot I will shift everything all the way left with < and repeat it with . and then re-indent everything.
Another solution is to use the unix fmt command as described in Your problem with Vim is that you don't grok vi., {!}fmt

Resources