История и дубликаты

Чтобы, во время листания истории введённых команд (стрелками на клавиатуре), терминал не предлагал вам одни и те же строки-дубликаты добавьте к .bashrc это:

export HISTCONTROL=ignoreboth:erasedups

Autocomplete

Если у вас имеется некий большой скрипт, и вы всё никак не можете уложить в голове все его многочисленные параметры, то можно создать свой собственный autocomplete-список для этого скрипта/программы. Сами скрипты обычно кладутся в ~/.bash_completion.d,  но это зависит от настроек вашей системы и профиля. Можно сделать, к примеру так (.bashrc):

if [ -f /etc/bash_completion ] && ! shopt -oq posix; then
    . your_script's_path
fi

Где вместо your_script's_path путь к вашему скрипту. В самом скрипте уже может быть всё что угодно. Самый простой вариант с заранее заготовленными строками для автокомплита (бездумного):

complete -W "option1 option2 option3" your_program

Это приведёт к тому, что вбив "your_program " и нажав Tab дважды вам будут предложены все три опции. Если же нужно что-то хитрее, например специфическую фильтрацию, то можно указать отдельный метод, для обработки уже введённых символов. Или, скажем, вам может потрбоваться в качестве списка вариантов список директорий/файлов в каком-то конкретно заданном месте.

_your_program()
{
    local cur=${COMP_WORDS[COMP_CWORD]}
    COMPREPLY=( $(compgen -W " $( ls some_directory's_path )" -- $cur) )
}
complete -F _your_program your_program

Этот код позволит по Tab-у получать в помощь список файлов из some_directory's_path.

#!/bin/sh

Столкнулся с тем, что указывая вначале bash-скриптов этот интерпретатор, часть правильно записанных bash-команд не срабатывает, а ругается с ошибками. Оказалось всё дело в том, что в Ubuntu-based дистрибутивах в качестве sh-интерпретатора используется некий dash, и он не в полной мере совместим с bash. Поменяв sh на bash в этой строке проблемы испарились.

В моём случае dash ругался на:

DIR=$(dirname "$(readlink -f "$0")")

Эта строка, кстати, аналог получения __dirname.

Столкнулся с неприятным багом/особенностью. Сразу к сути: в onclick в зависимости от используемого браузера могут как попадать клики средней кнопкой мыши, так и не попадать. В моём случае вышло так:

• Chrome 55, win ― не попадают
• Chrome 55, linux ― не попадают
• Chromium 53, linux ― попадают
• Firefox, linux ― не попадают

Столкнувшись с подобными проблемами, дабы точно знать, что дело в браузере, рекомендую тестировать на пустой странице, без какого-либо кода, отключив все расширения (--disable-extensions). Тестировать самый примитивный код. В моём случае всё свелось к onclick по любому тегу и console.log события.

Положим вы закачивали на сервер большой файл. Но с дуру выключили на ночь компьютер. Или, скажем, у вас отключили интернет. Или свет. Да мало ли что. Как докачать файл? Оказалось очень просто и без бубнов:

rsync --partial --progress -rsh=ssh %file% %destination%

 Формат для %file% и %destination% тот же, что и у scp. Как всегда, спасибо stackoverflow.

Примитивный скрипт на JavaScript, подсчитывающий кол-во повторений английских слов без учёта морфологии и пр. лингво-хитростей:

"use strict"; /* eslint-env es6 */

const fs = require('fs');

function calculate(source)
{
	const words = source
		.toLowerCase()
		.replace(/[^a-z0-9'’]+/gm, ' ')
		.split(/\s+/)
		.filter(s => s.length)
		.reduce((map, word) =>
		{
			if(!map.get(word))
				map.set(word, 0);
			map.set(word, map.get(word) + 1);
			return map;
		}, new Map());

	return Array.from(words)
		.sort((a, b) => a[1] < b[1] ? 1 : -1);
}

const [,, sourceF, destinationF ] = process.argv;
if(!fs.existsSync(sourceF))
	throw new Error('Couldn\'t find "' + sourceF + '" file');

const source = fs.readFileSync(sourceF).toString();
const words = calculate(source);
console.info('Found ' + words.length + ' words.');

const str = words
	.map(([word, count]) => `${word} = ${count}`)
	.join('\n');
fs.writeFileSync(destinationF, str);
console.info('Count-map\'s written into "' + destinationF + '" file');

Из простых, но действенных, решений можно фильтровать все слова:

1. с апострофами (Mike's, I'm, You're, Can't, Don't, You'll, etc)
2. отдельно стоящие числа (или вообще все слова с числами)

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

Как минимум:

• Актуальная версия RHL в какой-то глубокой бете. Некоторые инструменты, такие как onsen monaca, в итоге, прибиты ногами к конкретной версии (иначе оно попросту не работает). Даже готовые пресеты для webpack-а завязаны на конкретные версии. Обратной совместимостью там и не пахнет. Даже сообщений внятных о том, что изменилось в stack trace-ах не ждите. 
• Webpack server довольно хитро устроен внутри, поэтому такую связку очень сложно дебажить. Попробуйте ради интереса убрать [HMR] и [WDS] сообщения. В настройках плагинов такой опции нет. Попытка вырезать их из кода руками заставит вас детально разобраться в работе этого сервера. Ну или забить. Я забил :)
• Если ошибка произошла до первого успешного render-а, то stack trace показывает погоду на Марсе. Настоящая ошибка теряется в дебрях обёрток для ошибок.
• Если в Chrome Developer Tools для webpack's sourceMap-ов есть какая-то кривоватая, но поддержка, то в Firefox инструментах там просто хаос. Про stack trace-ы вообще молчу. Там просто ссылка строку в bundle.js. 
• React Hot Loader по понятным причинам не перегружает обновления методов, которые были за-bind-ны в contructor-е компонента сами на себя. В итоге приходится перегружаться почти по любому поводу.
• Любые не тривиальные случаи приводят к необходимости обновить страницу.

Сложилось стойкое впечатление, что 3-ая версия React Hot Loader-а всё ещё слишком сырая, чтобы ей можно было пользоваться за пределами задач вёрстки. Но я бы не стал даже в их пределах. Этот инструмент оборачивает всё своими proxy-методами, чем сильно портит жизнь.

Поддержка sourceMap-ов тоже пока оставляет желать лучшего. Слишком часто при debug-инге проваливаешься невесть куда, не можешь поставить breakpoint, а то и вовсе наблюдаешь какие-то аномалии. Поддержка stacktrace-ов тоже пока далека от идеала. 

Всё больше склоняюсь к разработке с ссылками на настоящие ресурсы, благо поддержка es6 в браузерах очень радует. Но вот JSX, я полагаю, нам в нативном виде в них не видать никогда. Так что вопрос, "а может к чёрту его этот JSX?" для меня лично достаточно актуален :)