abcd0x00

В C++ есть функция cout.flush(), которая, как написано в документации, "очищает буфер". Что это значит?

Это значит, что вывод на экран - слишком затратная операция, чтобы её выполнять для каждого символа по очереди. Поэтому символы пишутся в буфер (массив в оперативной памяти), а потом этот буфер один раз выводится на экран. Называется "буферизованный вывод".

Что делать в таких случаях?

Переименовать удалённый источник (origin). Это добавляешь источник, который нужно сделать первоначальным, под каким-нибудь именем. Затем удаляшь источник с именем origin, а потом переименовываешь добавленный источник с какого-то имени на origin.
Все команды описаны в помощи:
git remote --help
(Есть там и покороче варианты, но длинным способом ты делаешь для того, чтобы в случае каких-нибудь ошибок не потерять путь и всё проделать снова.)

если я работаю администратором никсов где-нибудь и дадут написать программу, опять же, которая расчитывает что-то там космическое, а ты ни формул, ничего не знаешь

Если ты сисадмин, то не должен писать программ, так как у тебя нет образования. Многие сисадмины думают, что они хорошие программисты, но сколько я кода не встречал от них, это такое фуфло, которое сломается при первой же накладке какой-нибудь.
В общем, программирование и администрирование - это две разные области. В одной дофига инфы и в другой дофига инфы, и они вообще не пересекаются ни в чём. Поэтому ты не можешь быть и тем и другим одновременно, так как у тебя времени просто не хватит изучить обе области сразу.

getlineno()
{
    sed -n "$2{p;q}" "$1"
}

username=`getlineno datafile.txt 2`
password=`getlineno datafile.txt 3`
database=`getlineno datafile.txt 1`

sudo mysqldump -u$username -p$password $database > $database.sql

unset password username database

>>> def f(s):
...     words = ('слово1', 'слово2', 'слово3')
...     for w in words:
...         if w in s:
...             return w
... 
>>> f('abc слово2 def слово1 ghi')
'слово1'
>>> f('abc def ghi')
>>>

Затрагивается ли сам файл, или может изменения вносятся куда-то (итнересно, куда), в файловую систему

Сам файл не затрагивается. Управление файлом происходит через его inode. Inode - это такая структура в файловой системе, описывающая файл. Когда ты запускаешь ls, она не заходит в файлы, а проходит по их inode'ам, читая из них информацию. А содержимое файла записывается в inode в виде адреса первого блока. Вот по этому inode и определяется, что можно делать с содержимым файла.

Используй
git add -p
Тогда можно весь день что-то писать, а в конце дня раскидывать это всё по разным коммитам.

И у меня появился вопрос: куда все это выложить

Опыт показывает, что всё это можно выкинуть, так как нужно оно только для самообучения (формирования мозгов). Хранить надо только то, чем пользуешься постоянно (шаблоны кода).

>>> import re
>>> 
>>> s = '( 10 + 20 ) * 3 + 5'
>>> 
>>> re.findall(r'\d+|[+\-*/()]', s)
['(', '10', '+', '20', ')', '*', '3', '+', '5']
>>>

Для установки софта из исходников обычно используют три команды:

./configure
make
sudo make install

Но не надо ставить из исходников то, что есть в репозиториях.

Не нужно писать system("pause") или cin.get(). Нужно просто сделать ярлык на cmd.exe в папке с программой и стереть в его свойствах путь к рабочему каталогу. Так консоль будет запускаться прямо в этой папке, в ней уже можно будет вполнять программу.

Вопрос вот в чем, на стороне клиента на javascript я формирую бинарные данные и отправляю их по веб сокету

Ты должен их сериализовать в какой-нибудь определённый (или стандартизованный) формат типа json или xml и потом разбирать такие данные на принимающей стороне.

Даже сишные данные с одной машины на другую не передаются прямо, потому что одна и та же сишная программа может иметь разные размеры одних и тех же типов на разных компах.

Можно ли язык C заменить perl?

Их надо знать оба. Бывает так, что основная программа пишется на C, а управляющий скрипт для этой программы пишется на интерпретируемом языке (Perl'е или Python'е).

Почему в вузах изучают C - потому что он содержит всё необходимое и не содержит ничего лишнего (можно сконцентрироваться на задаче).

Вот ты запускал какой-нибудь скрипт на Perl'е? А знаешь, что он выполнялся в интерпретаторе, который написан на C? На C написано много всего, о чём ты даже не думаешь. Даже этот сайт работает через nginx, а nginx написан на C.

Если ты выберешь один Perl, то не сможешь понимать исходники на C. А исходников на C с какими-либо примерами (вращение деревьев, например) больше, чем исходников на Perl'е. Так тебе нужно будет что-нибудь узнать, а ты не сможешь, потому что исходников на Perl'е не будет нигде.

Есть два разных понятия: правильность набора и скорость набора. И, соответственно, есть программы только для первого и есть программы только для второго. Их часто путают.

Вот для правильности нужно изучить постановку рук над клавиатурой и нюансы движений пальцев. Там, например, бывают одиночные буквы и те же самые буквы в буквосочетаниях. Это разные случаи и пальцы нужно двигать по-разному. А чтобы пальцы двигались сами (рефлекторно), это нужно медленно повторять одно и то же очень много раз. Вот эту всю теорию нужно где-то взять, сам ты её из космоса не поймёшь.

Поэтому есть две классические проги - Соло и Стамина. Вот первая - для первого (теории), вторая - для второго (для практики).

А теперь немного погуглив, нашёл язык Go, что, мол он тоже почти похож как Си, но только легкий для освоения.

Нет, он сделан гораздо хуже, чем C. В нём многие недоделки выдаются за такие якобы гениальные возможности. Например, необходимый копипаст или if'ы на три страницы выдаются за очень ясный код, поэтому его типа так много. А дело только в том, что они придумали, что фигурные скобки должны стоять всегда и на отдельных строках. В C функция занимает одну или две строки, в Go та же самая функция занимает шесть строк и это всё выдаётся за гениальность. В итоге код из трёх функций в C занимает 25 строк, а в Go - три страницы. Также если брать длину строки в коде, то в Go вернулись к длинным строкам в стиле PHP, когда это всё просто невозможно читать, потому что для прочтения одной строки нужно три раза ходить чай пить. Когда в Питоне, например, вводят правило 80 символов на строку, которого даже в C не было, хотя оно хорошее и снимает много проблем, то в Go делают наоборот и на все вопросы заявляют, что они гении, поэтому знают, как лучше. Поэтому никакого желания читать Go'шный код нет, так как каждый раз ты знаешь, что это неповоротливый код в три строки, размещённый на трёх страницах.

Собираю емакс.

Поставь его из репозитория. Судя по вопросам, тебе ещё рано что-либо собирать, потому что ты даже не знаешь, что такое библиотека.

Может есть какие то средства? Или программы?

Есть sed, но его нужно знать.

Можно так поделить: .h - если эти файлы можно использовать в проекте на C; .hpp - если эти файлы можно использовать только в проекте на C++.

Насколько дурным тоном будет реализовать весь такой класс в одном файле (в .h например)?

Их специально сделали отдельными, потому что они не компилируются, а только вставляются напрямую через include. Некоторые расчитаны на единственную вставку (тогда делаются ворота из ifndef), а некоторые - на множественную вставку (тогда и ворота из ifndef не нужны). И вот когда они вставлены, тогда они и компилируются уже в контексте того места, куда они вставлены.
Назначение файлов .h - сделать видимыми имена (объявить имена).