Как bash понимает какой переменной оперировать?

Leks: да, с кавычками разберись, а то и awk у тебя неправильно записан. Фигурные скобки являются частью кода, который в awk передаётся через аргумент awk. Поэтому в кавычки надо брать весь код, который подаётся в awk.
awk -F '|' '{print $1}'

Как реализовать корректный поиск строк на С?

witalianno:

однако меня заинтересовал более тривиальный подход к вводу текста

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

Как реализовать корректный поиск строк на С?

Это задача из K&R2.

BASH скрипт, почему не проходит сравнение?

У тебя ещё varloss неправильно создаётся. Надо обернуть цепочку команд в $() или в обратные кавычки.

Стоит ли изучать GoLang вместе с изучением алгоритмов?

qweqwa:

Я уже больше 10 лет читаю....

Так а что ты тогда не знаешь такие команды, как blame или bisect? Я постоянно смотрю откуда появилось изменение, кто его внёс. И ссылается оно не всегда на неделю-две. Бывает, что просто надо понять, зачем сделали такой-то кусок, вот отыскиваешь автора и смотришь за его действиями в каком-то там году. Так что...

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

Смотри, ты форматируешь отступы в табы, а потом у себя настраиваешь их. У табов преимущество только в том, что они один байт занимают - один оступ = один байт. Но недостатки я привёл выше, и ты сказал, что это github какой-то не такой. Это не github, это форматировщик негибкий.

Стоит ли изучать GoLang вместе с изучением алгоритмов?

qweqwa:

или базовая технология как git

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

Стоит ли изучать GoLang вместе с изучением алгоритмов?

qweqwa: три года - поколение? Не видал коммитов, которым по 20 лет?

[guest@localhost main]$ git log1 be840
commit be84045f0780b31d4ff08042daf27c9521ccf393
Author: Guido van Rossum <[e-mail]>
Date:   Thu Aug 9 14:25:15 1990 +0000

    Initial revision
    
    --HG--
    branch : legacy-trunk
    extra : convert_revision : svn%3A6015fed2-1504-0410-9fe1-9d1591cc4771/python/branches/leg

[guest@localhost main]$

Три года - это вообще ничто. Оглянуться не успел, пять лет пролетело.

Стоит ли изучать GoLang вместе с изучением алгоритмов?

cijiw: а ты какие виды ПО знаешь?

Как в Ubuntu изменить имя файла на транслит и перед каждым изменённым символом поставить флаг?

ILoveYAnny: любые нераспознанные символы попадают в последний пункт - остаются в том же виде.

Стоит ли изучать GoLang вместе с изучением алгоритмов?

cijiw:

вы предлагаете мержить коммиты без просмотра кода, что ли? ;)

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

Стоит ли изучать GoLang вместе с изучением алгоритмов?

cijiw:

Я согласен с @qweqwe типичные коммиты содержат очень небольшие компактные комментарии.

Типичный коммит содержит описание, достаточное для понимания изменений. Хреновый коммит содержит описание, после которого нужно смотреть код изменений, иначе ничего не понятно.

Как происходит выделение памяти под читаемый файл?

beduin01: он читает через файловый буфер в любом случае. Размер файлового буфера фиксирован. Так система открывает много файлов и все их читает (у каждого свой буфер). Если бы она читала целиком, то у неё не хватило бы памяти на всё. Например, файл - 10Gb, а оперативной памяти - 4Gb. Если же ты читаешь целиком, то это просто чтение кусков через буфер и объединение их в одном месте.

Как происходит выделение памяти под читаемый файл?

beduin01:

Хранит ли ФС информацию о размере файла или каждый раз она заново пересчитывается?

Размер файла записан прямо на диске и хранится до тех пор, пока файл не изменится. Ты когда свойства папки нажимаешь в файловом менджере, он начинает собирать эту информацию из описания каждого файла в этой папке, чтобы показать тебе размер папки. То есть он не читает файлы, а читает их описания, которые хранятся рядом с файлами. Если бы он читал файлы до конца, чтобы определить их размер, ты бы не дождался информации.

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

Стоит ли изучать GoLang вместе с изучением алгоритмов?

qweqwa:

это ядро операционной системы

Какое ядро, ты не знаешь, что git разработал Линус Торвальдс? Я тебе не про ядро, а про сам git, у которого есть репозиторий. Вот скачай себе и почитай, как там коммиты пишут.
https://git.kernel.org/pub/scm/git/git.git

Как перевести курсор на новую строку при чтении из файла в СИ?

Ты вообще зачем восьмеричные коды определяешь для символов, которые и так есть в языке?
CR - '\r'
LF - '\n'
printf("%o %o\n", '\r', '\n');

Как перевести курсор на новую строку при чтении из файла в СИ?

Иван Громов: да это просто туфта какая-то. Открыл файл в текстовом режиме, а потом в нём переход на байтовую позицию выполняет.

Стоит ли изучать GoLang вместе с изучением алгоритмов?

qweqwa:

потому как их делаешь по 2 десятка в день. придумывать задолбаешься.

Не, просто есть программы, в которые они не поместятся. Поэтому заголовочная строка коммита короткая, а текст может быть шире. Насчёт придумки, так ты не читал просто коммитов Линуса Торвальдса в репозитории git'а. Вот там у него целые произведения на несколько страниц.

Стоит ли изучать GoLang вместе с изучением алгоритмов?

qweqwa:

Веб-инерфейс ГитХаба никакого отношения к работе с кодом не имеет. Работают локально. В своей репе git.

С двумя пробелами (да даже с четырьмя) ты бы так не говорил. Ты бы говорил "какой прекрасный интерфейс!".

А ты не знаешь, что коммиты принято делать с очень короткими заголовками? Ты не думал, почему так принято? Мониторы же уже большие сегодня.

Если бы он портил картину, то возмущались бы толпы. Возмущаешься ты один.

Остальные просто этим не пользуются. Уже 2009 год давно прошёл, а из него как всё торчало, так и торчит дальше. "Допиши сам" - ну, ты смешной, мне больше делать нечего что ли? У меня дел хватает.

Стоит ли изучать GoLang вместе с изучением алгоритмов?

qweqwa:

Вы не прониклись проблемой с коммитами. Разжевываю:

Так я не про коммиты говорю. Представь, что у тебя проект, в котором отступ в два пробела. И у тебя там блоки вложены на большую глубину (потому и два пробела, чтобы можно было не думать о глубине). С двумя пробелами они смотрятся хоть где, хоть в настроенной системе, хоть в ненастроенной системе. И даже на github'е через веб-интерфейс они будут смотреться прекрасно. (Ведь ты же знаешь, что на github'е слишком длинные строки обрезаются.) А с go fmt у тебя такие хорошие коммиты, но на github'е через веб-интерфейс ты их не просмотришь.

Вот пример, там как раз такие строки есть, которые вылазят за край. Ну да, сделали там скролл на github'е, которого раньше не было, но не суть. Так вот, они вылазят как раз потому что нужно глубоко вкладывать (это не просто бзик какой-то, а реальная потребность), а отступы в виде табуляций отображаются как восемь пробелов. И не настроишь ты github, чтобы он отображал меньше пробелов на каждую табуляцию.

Поэтому я хочу взять и сделать отступы в четыре пробела во всём проекте (чтобы все программисты-участники писали четыре во всех коммитах). Но этот дурацкий go fmt не даёт мне этого сделать, навязывая свою хрень.

3 минуты - форкаешь, ищешь в исходнике табы, заменяешь пробелами, компилируешь вариант под себя.

Ага, а то, что эти табы могут быть не только отступами, но и нужными табами где-нибудь в комментариях, которые не надо трогать, это ты как-то упустил. Это не просто взял и заменил.

Если этого мало, то в состав стандартных пакетов Go входит пакет для работы с AST языка Go.

Да написать-то я могу без всякого AST и без всякого Go, но вопрос-то остаётся: почему я в программе не могу отключить один из сотни элементов, который всю картину портит?

Есть ли способы помимо передачи списка из find, заставить rsync синхронизировать только файлы, созданные более минуты назад?

Надо как-то отслеживать появление готовых файлов и подавать их список в rsync, который не должен делать ничего, кроме своей задачи. Так ты сможешь заменять как отслеживающую часть, так и копирующую отдельно друг от друга.