Максим Шадрин

www.bootply.com/XYVEABrrDO

Тут 2 варианта:

1. Заказывают верстку, подразумевают создание шаблона/темы для CMS. По хитрости, по не знанию, по глупости - не важно. Важно не подписаться пилить это по цене только верстки.

Верстка - это когда макет превращается в набор html/css/js файлов.

Да, могут быть вариации. Может быть сразу под движок: Smarty, Twig, Jade, или все шаблоны в Handlebars, или сразу чтобы всё под Angular было. Но это всё частные случаи, требующие более высокой квалификации, или находящиеся уже где-то во front-end разработке.

2. Просят учесть особенности CMS.

Маленьких нюансов может быть много.

Вот Битрикс, например, и его Эрмитаж (тыкнул в блок - тут же его отредактировал если по простому). Где-то лишняя обертка элемента, чтобы в режиме редактирования не разваливалось. Везде - z-index меньше 1000, чтобы Эрмитаж не перекрывало.

Wordpress вообще генерирует огромное количество своих классов. Взять те же навигационные меню. Использовать их = наплевать на все эти ваши БЭМ и прочее.
И т.д.

Если я верстал и без проблем натягивал свои макеты на Wordpress - могу ли сказать что у меня есть опыт верстки под Wordpress?

Могу.
Так же как могу сказать что есть опыт верстки под Drupal (не знаю натягивали ли какие-то из моих работ на Drupal, но чё бы нет).

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

.nav
    .nav__list
        .nav__item

Когда ему движок выдаст меню в виде

.menu
    ul
        li

Но я не считаю это своей проблемой.
Когда понадобилось, оказалось нет ничего сложного 1 раз потратить время и написать свой вывод меню в Wordpress, чтобы можно было любую верстку натянуть. Почему так не может сделать тот кто натягивает? Почему в ТЗ об этом не предупредили?

Уменьшает ли "опыт верстки под CMS" время верстки?
Если не были оговорены нюансы (те же меню WP) - то нет.
Может увеличиться время натягивания верстки на движок, но это уже проблемы заказчика, который не озвучил требования заранее.

Таким образом, хотя в идеале на движок должно быть возможным натянуть любую верстку, действительно некоторые имеют CMS особенности.
Об этих особенностях следует договариваться заранее. Должно быть конкретное ТЗ на верстку.
В остальном как правило речь об "опыте верстки под %CMS%" - просто болтовня.

В вордпресс есть замечательные условные теги, как например is_page() , в параметрах которых вы можете передать ID страницы/поста и соответственно получиться:
if (is_page(id)){
wp_enqueue_script('needFullScript'); // В теле функции подключаем нужный скрипт, перед этим его регистрируем с помощью wp_register_script()
}

Если список файлов навсегда останется как есть -- то и так все нормально, только лучше бы #!/bin/bash поменять на #!/bin/sh

А вот если ожидается, что количество или расположение копируемых файлов будет хотя бы иногда меняться -- я бы сделала так:

#!/bin/sh

for file in \
    /etc/squid/URLs/accessed/access.sorted \
    /etc/squid/URLs/accessed/oper_kass_url \
    /etc/squid/URLs/denied/deny.url.uniq \
    ;
do
    cp $file /home/security/urls/
done

for file in \
    /etc/squid/groups/full.dom \
    /etc/squid/groups/limit.dom \
    /etc/squid/groups/oper_kass.dom \
    /etc/squid/groups/unlim.dom \
    ;
do
    cp $file /home/security/groups/
done

for file in \
    /etc/squid/squid.conf \
    ;
do
    cp $file /home/security/urls/
done

На скорость работы не влияет, по строчкам получается даже больше, чем в исходном варианте, и существенно больше, чем в предложении gen1s.
Зато исходные файлы и целевые каталоги разнесены по разным строкам, а это легче читается и проще правится. Если надо добавить копирование еще одного или нескольких файлов -- просто добавляем однотипные строки. Выкинуть файл из копирования -- удалить строку. Ошибиться невозможно ^_^

На всякий случай: после бекслешей не должно быть пробелов (это способ разбить длинную команду на несколько строк).

Не думаю, что в этом есть смысл (быстрее ничего точно не станет). Но можно писать и так:

#!/bin/bash
cp -f /etc/squid/URLs/accessed/{access.sorted,oper_kass_url} /home/security/urls/
cp -f /etc/squid/URLs/denied/deny.url.uniq /home/security/urls/
cp -f /etc/squid/groups/{full.dom,limit.dom,oper_kass.dom,unlim.dom} /home/security/groups/
cp -f /etc/squid/squid.conf /home/security/

Так? jsfiddle.net/Zoxon/f58VP/1