«террабайтник» читать как «полу-террабайтник» или предположить, что мы от него только половину отформотировали под /home_new. (*иногда полезно самого себя перечитывать. иногда уже поздно*)
Пересилил лень и решил в общем треде напомнить про unionfs, которая живет под *BSD и есть нативный порт под Linux.
Если рассуждать в масштабах проблем автора, то алгоритм такой.
Цепляем новенький террабайтник.
Форматируем и создаем на нем /home_new
Переименовываем /home в /home_old
Создаем новый /home
Unionfs монитируем на /home /home_old с правами RO и /home_new RW
Получаем х+500Gb данных
Радостно ждем, когда загнется старый диск.
Достаем новый диск (500Gb) из компа и цепляем к ноуту — «Смотри мама, все живо!»
Как человек собственной жопой прочувствовавший, что уровень рейда не влияет на качество фарша из данных, если того захотел контроллер — поддерживаю!
Террабайт белого шума из 4-х хардов на 5-ом рейде начисто отучили доверять передачу данных устройствам сложнее шлейфа.
Есть unionfs — позволяет объединять логические разделы в один большой, с последовательным заполнением.
Т.е. есть 2 диска по 100 Gb — объединяем — первые 100 Gb пишутся на первый диск, следующие — на второй.
Прогиб по скорости, НО — если что-то умрет — оно умрет только со своим куском данных.
Погуглите.
Не совсем понял
| оно применяется к тексту, который не состоит в тегах. то есть само должно искать в сообщении теги.
Я в общем-то только из практических соображений.
1. можно написать \url{href} дабы содержимое гарантировано стало выглядеть как ссылка
2. можно написать \url{href desc} дабы второе было отображеним первого
3. проще для восприятия, т.к. сущность href-desc в общем-то атомарна (на мой взгляд — desc без href — просто текст)
4. проще писать — не выпадает из канвы \teg{item}
Т.о. имеем тег \url{href desc} и правило для подсветки url, которые друг другу не мешают (правило отучаем вмешиваться в тег)
Мда. Хотел пошутить, но не буду, времена суровые — не поймут.
Вообще-то стандарт предписывает ::= [ [ <ldh-str> ] <let-dig> ]
т.е. оно вообще невалидно, т.к. с цифры начинаться не может, но ладно.
тогда так — ([a-z0-9][-a-z0-9]{0,61}[a-z0-9]?\.)+([a-z]{2,6})
Кстати, если есть понимание — могу попробовать подумать что-нибудь оптимальное и для liveUrls и url.
Только я за синтаксис вида
\url{href desc}
Проще будет написать оба обработчика так, чтобы они не пересекались.
Да, сразу после @
Мой вариант — более канонический, что-ли.
если править Ваш, тогда
([a-z0-9][-a-z0-9]{0,61}[a-z0-9]\.)+([a-z]{2,6})
т.к стандарт вроде бы как требует не менее 2-х букв в имени
О!
Думаю обмен у нас с Вами равноценный.
Сурово :)
Кстати, чтоб не флудить — в liveEmails Ваше регулярное выражение потенциально имеет проблему, на мой взгляд.
Попробуйте SETI@HOME — Вы точно уверены, что именно это имелось ввиду?
Могу предложить
(?:(?:[a-z0-9][-a-z0-9]{0,61}[a-z0-9]\.)+(?:[a-z]{2}|com|org|net|gov|mil|biz|info|mobi|name|aero|jobs|museum))|local
(кто-то жаловался, что не может локальный адрес вводить)
Не смог пройти мимо :)
Идея отличная — думаю что поживлюсь для само-блога, как руки дойдут написать. Консоль родная всяко удобнее мышеклацкания, и метаться туда-сюда между полем ввода и кнопочами не надо.
Посильное предожение —
safeHTML : function (stringIn) {
var primer = {'&':'& amp;','\'':'& #039;','\"':'& quot;','<':'& lt;','>':'& gt'};
return stringIn.replace(/[<'&">]/g, function (symb) {return primer[symb]});
}
PS. В primer в значениях нужно удалить пробел-отбивку перед & :(
PPS. Как хабровый парсер заставить нарисовать именно & amp; а не & ??? Он просто-таки непобедим.
Terms that are composed of the LIKE or GLOB operator can sometimes be used to constrain indices. There are many conditions on this use:
1. The left-hand side of the LIKE or GLOB operator must be the name of an indexed column.
2. The right-hand side of the LIKE or GLOB must be a string literal that does not begin with a wildcard character.
3. The ESCAPE clause cannot appear on the LIKE operator.
4. The build-in functions used to implement LIKE and GLOB must not have been overloaded using the sqlite3_create_function() API.
5. For the GLOB operator, the column must use the default BINARY collating sequence.
6. For the LIKE operator, if case_sensitive_like mode is enabled then the column must use the default BINARY collating sequence, or if case_sensitive_like mode is disabled then the column must use the built-in NOCASE collating sequence.
Агрегируйтесь! :)
Меняя host — его и меняйте, какая вам разница до его составляющих?
PS. ИМХО решение задач в общем виде — убийство времени.
PPS. Меня там тоже немного покоцали, если решите променять универсальность на скорость и объем — ВЕЛКАМ!
Автор, Вы неподражаемы!
Прежде всего пара замечаний:
Ошибка в Вашем же схематическом изображении — HOST является контейнером для hostname и port — так зачем же Вы их стрелочками-то аттачите в HREF? При изменении любой из частей URL должны обновляться другие. — так и не постиг, как именно «другие» должны обновляться??? ИМХО связь (да и то — лишь теоретическая, бо никто не мешает Вам использовать порты и протоколы по своему усмотрению) в URL есть лишь в парах http => 80 и https => 443 — Вы об этом?
И один вопрос —
Конкретно мне надо было распарсить текущий URL и изменить/добавить новый параметр в search, с последующим редиректом.
Это конкретно все, что нужно было сделать?
var url_replace = function (new_text,del_old) {
var _stuff,_result,_test_url = window.location.href;
_stuff=((_stuff=test_url.match(/\?([^#]+)/))&&_stuff[1]); // при отсутствии search полУчите null
// теперь работайте с Вашим search
if (del_old&&_stuff) _result=test_url.replace(/\?([^#]+)/,'?'+new_text); //если нужно перезаписать search
else _result=test_url.replace(/(#)|$/,(!_stuff?'?':'&')+new_text+'$1'); // если нужно дополнить search
return _result;
}
var words = args[0].split(' ');
var href = words.shift();
var desc = words.join(' ');
->
var words = args[0].split(' ',1);
var href = words[0];
var desc = words[1];
тогда уж
Если рассуждать в масштабах проблем автора, то алгоритм такой.
Цепляем новенький террабайтник.
Форматируем и создаем на нем /home_new
Переименовываем /home в /home_old
Создаем новый /home
Unionfs монитируем на /home /home_old с правами RO и /home_new RW
Получаем х+500Gb данных
Радостно ждем, когда загнется старый диск.
Достаем новый диск (500Gb) из компа и цепляем к ноуту — «Смотри мама, все живо!»
Террабайт белого шума из 4-х хардов на 5-ом рейде начисто отучили доверять передачу данных устройствам сложнее шлейфа.
Т.е. есть 2 диска по 100 Gb — объединяем — первые 100 Gb пишутся на первый диск, следующие — на второй.
Прогиб по скорости, НО — если что-то умрет — оно умрет только со своим куском данных.
Погуглите.
Тираж 2000 экз. :(
| оно применяется к тексту, который не состоит в тегах. то есть само должно искать в сообщении теги.
Я в общем-то только из практических соображений.
1. можно написать \url{href} дабы содержимое гарантировано стало выглядеть как ссылка
2. можно написать \url{href desc} дабы второе было отображеним первого
3. проще для восприятия, т.к. сущность href-desc в общем-то атомарна (на мой взгляд — desc без href — просто текст)
4. проще писать — не выпадает из канвы \teg{item}
Т.о. имеем тег \url{href desc} и правило для подсветки url, которые друг другу не мешают (правило отучаем вмешиваться в тег)
Вообще-то стандарт предписывает ::= [ [ <ldh-str> ] <let-dig> ]
т.е. оно вообще невалидно, т.к. с цифры начинаться не может, но ладно.
тогда так — ([a-z0-9][-a-z0-9]{0,61}[a-z0-9]?\.)+([a-z]{2,6})
Только я за синтаксис вида
\url{href desc}
Проще будет написать оба обработчика так, чтобы они не пересекались.
Мой вариант — более канонический, что-ли.
если править Ваш, тогда
([a-z0-9][-a-z0-9]{0,61}[a-z0-9]\.)+([a-z]{2,6})
т.к стандарт вроде бы как требует не менее 2-х букв в имени
Думаю обмен у нас с Вами равноценный.
Сурово :)
Кстати, чтоб не флудить — в liveEmails Ваше регулярное выражение потенциально имеет проблему, на мой взгляд.
Попробуйте SETI@HOME — Вы точно уверены, что именно это имелось ввиду?
Могу предложить
(?:(?:[a-z0-9][-a-z0-9]{0,61}[a-z0-9]\.)+(?:[a-z]{2}|com|org|net|gov|mil|biz|info|mobi|name|aero|jobs|museum))|local
(кто-то жаловался, что не может локальный адрес вводить)
Идея отличная — думаю что поживлюсь для само-блога, как руки дойдут написать. Консоль родная всяко удобнее мышеклацкания, и метаться туда-сюда между полем ввода и кнопочами не надо.
Посильное предожение —
PS. В primer в значениях нужно удалить пробел-отбивку перед & :(
PPS. Как хабровый парсер заставить нарисовать именно & amp; а не & ??? Он просто-таки непобедим.
Смотрите последнюю (обновленную) версию, там сократить нельзя.
И далее по тексту.
Меняя host — его и меняйте, какая вам разница до его составляющих?
PS. ИМХО решение задач в общем виде — убийство времени.
PPS. Меня там тоже немного покоцали, если решите променять универсальность на скорость и объем — ВЕЛКАМ!
Но!
if (paramsUri && isReplace) {
return uri.replace(/\?[^#]+/, paramsNew ? '?' + paramsNew : paramsNew);
}
ХМ.
Масло маслянное, если у Вас paramsNew == '', так чего стесняться?
if (paramsUri && isReplace) {
return uri.replace(/\?[^#]+/, paramsNew ? '?' + paramsNew : '' );
}
И — завершающее return uri; — поясните, к чему так?
Кроме шуток — не понимаю смысла функции, возвращающей отданный ей аргумент. Тогда уж null, что ли.
Прежде всего пара замечаний:
Ошибка в Вашем же схематическом изображении — HOST является контейнером для hostname и port — так зачем же Вы их стрелочками-то аттачите в HREF?
При изменении любой из частей URL должны обновляться другие. — так и не постиг, как именно «другие» должны обновляться??? ИМХО связь (да и то — лишь теоретическая, бо никто не мешает Вам использовать порты и протоколы по своему усмотрению) в URL есть лишь в парах http => 80 и https => 443 — Вы об этом?
И один вопрос —
Это конкретно все, что нужно было сделать?
Вызывайте
url_replace('foo=bar')для дополнения илиurl_replace('foo=bar',1)для замены строки search