ធ្លាក់ទន្សាយ៖ រឿង វ៉ារនីស ផ្ទុកឡើងវិញ វគ្គ ១

ghostinushankaដោយបានញញួរប៊ូតុងអស់រយៈពេល 20 នាទីមុន ហាក់បីដូចជាជីវិតរបស់គាត់ពឹងផ្អែកលើវា ងាកមកខ្ញុំដោយភ្នែកពាក់កណ្តាលព្រៃ ហើយញញឹមយ៉ាងម៉ឺងម៉ាត់ - "ប៉ា ខ្ញុំគិតថាខ្ញុំយល់ហើយ"។

គាត់និយាយថា "មើលនៅទីនេះ" ដោយចង្អុលទៅនិមិត្តសញ្ញាមួយនៅលើអេក្រង់ "ខ្ញុំភ្នាល់មួកក្រហមរបស់ខ្ញុំថាប្រសិនបើយើងបន្ថែមនៅទីនេះនូវអ្វីដែលខ្ញុំទើបតែផ្ញើឱ្យអ្នក" ដោយចង្អុលទៅផ្នែកផ្សេងទៀតនៃកូដ កំហុសនឹងលែងមានទៀតហើយ។ នឹងត្រូវបានបង្ហាញ។"

មានការងឿងឆ្ងល់ និងអស់កម្លាំងបន្តិច ខ្ញុំកែប្រែកន្សោម sed ដែលយើងកំពុងធ្វើការមួយរយៈ រក្សាទុកឯកសារ ហើយដំណើរការ systemctl varnish reload. សារកំហុសបានបាត់...

មិត្តរួមការងាររបស់ខ្ញុំបានបន្តទៀតថា "អ៊ីមែលដែលខ្ញុំបានផ្លាស់ប្តូរជាមួយបេក្ខជន" មិត្តរួមការងាររបស់ខ្ញុំបានបន្ត នៅពេលដែលស្នាមញញឹមរបស់គាត់ក្លាយជាស្នាមញញឹមដ៏រីករាយ "ភ្លាមៗនោះវាបានភ្លឺមកលើខ្ញុំថា នេះពិតជាបញ្ហាដូចគ្នា!"

របៀបដែលវាទាំងអស់បានចាប់ផ្តើម

អត្ថបទសន្មតថាការយល់ដឹងអំពីរបៀបដែល bash, awk, sed និងប្រព័ន្ធដំណើរការ។ ចំណេះដឹងអំពីវ៉ារនីសត្រូវបានគេពេញចិត្ត ប៉ុន្តែមិនចាំបាច់ទេ។
ត្រាពេលវេលានៅក្នុងអត្ថបទខ្លីៗត្រូវបានផ្លាស់ប្តូរ។
សរសេរជាមួយ ghostinushanka.
អត្ថបទនេះគឺជាការបកប្រែដើមដែលបានបោះពុម្ពជាភាសាអង់គ្លេសកាលពីពីរសប្តាហ៍មុន; ការបកប្រែ បូកូដិន.

ព្រះអាទិត្យរះតាមបង្អួចបែប Panoramic នៅព្រឹករដូវស្លឹកឈើជ្រុះដ៏កក់ក្តៅមួយផ្សេងទៀត ភេសជ្ជៈសម្បូរជាតិកាហ្វេអ៊ីនដែលរៀបចំថ្មីៗ សម្រាកចេញពីក្ដារចុច សំឡេងចម្រៀងដែលអ្នកចូលចិត្តបន្លឺឡើងនៅក្នុងកាសរបស់អ្នក ធ្វើឲ្យលិចលង់នៃក្ដារចុចមេកានិច និងធាតុទីមួយ នៅក្នុងបញ្ជីសំបុត្រត្រលប់មកវិញនៅលើក្តារខៀនបានបញ្ចេញពន្លឺយ៉ាងសប្បាយរីករាយជាមួយនឹងចំណងជើងជោគវាសនា "ស៊ើបអង្កេត varnishreload" sh: បន្ទរ: កំហុស I/O នៅក្នុងដំណាក់កាល" (ស៊ើបអង្កេត "varnishreload sh: echo: I/O error" នៅក្នុងដំណាក់កាល) ។ នៅពេលដែលវាមកដល់ វ៉ារនីស វាមាន និងមិនអាចមានកន្លែងសម្រាប់កំហុសណាមួយឡើយ ទោះបីជាវាមិនបណ្តាលឱ្យមានបញ្ហាអ្វីដូចករណីនេះក៏ដោយ។

សម្រាប់អ្នកដែលមិនសូវស្គាល់ varnishreloadនេះ​ជា​ស្គ្រីប​សែល​សាមញ្ញ​ដែល​ប្រើ​ដើម្បី​ផ្ទុក​ការ​កំណត់​រចនាសម្ព័ន្ធ​ឡើង​វិញ។ វ៉ានីស - ហៅផងដែរថា VCL ។

ដូចដែលចំណងជើងនៃសំបុត្របានបង្ហាញ កំហុសបានកើតឡើងនៅលើម៉ាស៊ីនមេមួយនៅលើឆាក ហើយដោយសារខ្ញុំប្រាកដថា ការដាក់វ៉ានីសនៅលើឆាកដំណើរការបានត្រឹមត្រូវ ខ្ញុំបានសន្មត់ថានេះជាកំហុសតូចតាច។ ដូច្នេះ គ្រាន់តែជាសារដែលបានបញ្ចប់នៅក្នុងស្ទ្រីមទិន្នផលដែលបានបិទរួចហើយ។ ខ្ញុំយកសំបុត្រសម្រាប់ខ្លួនខ្ញុំ ដោយមានទំនុកចិត្តពេញលេញថា ខ្ញុំនឹងសម្គាល់វារួចរាល់ក្នុងរយៈពេលតិចជាង 30 នាទី ហើយទះកំផ្លៀងខ្លួនខ្ញុំនៅលើខ្នងដើម្បីសម្អាតក្តារបន្ទះសំរាមផ្សេងទៀត ហើយត្រលប់ទៅបញ្ហាសំខាន់ជាងនេះ។

បុកជញ្ជាំងក្នុងល្បឿន ២០០ គីឡូម៉ែត្រក្នុងមួយម៉ោង

ការបើកឯកសារ varnishreloadនៅលើម៉ាស៊ីនមេមួយក្នុងចំណោមម៉ាស៊ីនមេដែលស្ថិតនៅក្រោមការគ្រប់គ្រង Debian លាតត្រដាង ខ្ញុំបានឃើញស្គ្រីបសែលដែលមានប្រវែងតិចជាង 200 បន្ទាត់។

ដោយបានឆ្លងកាត់ស្គ្រីប ខ្ញុំមិនបានកត់សម្គាល់អ្វីដែលអាចបង្កបញ្ហាទេ ប្រសិនបើខ្ញុំដំណើរការវាច្រើនដងដោយផ្ទាល់ពីស្ថានីយ។

យ៉ាងណាមិញ នេះជាដំណាក់កាលមួយ ទោះបីបែកក៏គ្មានអ្នកណារអ៊ូរទាំដែរ… មិនច្រើនពេកទេ។ ខ្ញុំដំណើរការស្គ្រីប ហើយមើលអ្វីដែលនឹងត្រូវបានសរសេរទៅស្ថានីយ ប៉ុន្តែកំហុសមិនអាចមើលឃើញទៀតទេ។

ដំណើរការពីរបីទៀត ដើម្បីប្រាកដថាខ្ញុំមិនអាចបង្កើតកំហុសឡើងវិញបានទេ បើគ្មានការប្រឹងប្រែងបន្ថែមទេ ហើយខ្ញុំកំពុងចាប់ផ្តើមរកវិធីផ្លាស់ប្តូរស្គ្រីបនេះ ហើយធ្វើឱ្យវានៅតែមានកំហុសដដែល។

តើស្គ្រីបអាចបដិសេធ STDOUT (ដោយប្រើ > &-)? ឬ STDERR? ទាំងពីរនេះមិនដំណើរការនៅទីបញ្ចប់ទេ។

តាមមើលទៅប្រព័ន្ធបានកែប្រែបរិយាកាសចាប់ផ្ដើម ប៉ុន្តែរបៀប និងហេតុអ្វី?
ខ្ញុំបើក vim ហើយកែសម្រួល varnishreload, បន្ថែម set -x នៅក្រោម shebang ដោយសង្ឃឹមថាលទ្ធផលបំបាត់កំហុសនៃស្គ្រីបនឹងបញ្ចេញពន្លឺខ្លះ។

ឯកសារត្រូវបានកែដំរូវ ដូច្នេះខ្ញុំផ្ទុកវ៉ារនីសឡើងវិញ ហើយឃើញថាការផ្លាស់ប្តូរបានខូចទាំងស្រុង... ការហត់នឿយគឺរញ៉េរញ៉ៃទាំងស្រុង ដែលក្នុងនោះមានលេខកូដ C-like រាប់សិប។ សូម្បីតែការរមូរនៅក្នុងស្ថានីយក៏មិនគ្រប់គ្រាន់ដើម្បីស្វែងរកកន្លែងដែលវាចាប់ផ្តើមដែរ។ ខ្ញុំច្រឡំទាំងស្រុង។ របៀបបំបាត់កំហុសអាចប៉ះពាល់ដល់ប្រតិបត្តិការនៃកម្មវិធីដែលបានបើកនៅក្នុងស្គ្រីប? ទេ វាមិនសមហេតុសមផលទេ។ កំហុសនៅក្នុងសែល? សេណារីយ៉ូដែលអាចកើតមានជាច្រើនកំពុងរត់កាត់ក្បាលរបស់ខ្ញុំដូចជាសត្វកន្លាតក្នុងទិសដៅផ្សេងៗគ្នា។ ពែងនៃភេសជ្ជៈដែលមានជាតិកាហ្វេអ៊ីនត្រូវបានទទេភ្លាមៗ ការធ្វើដំណើររហ័សទៅកាន់ផ្ទះបាយដើម្បីបំពេញស្តុក ហើយ... យើងទៅ។ ខ្ញុំ​បើក​ស្គ្រីប​ហើយ​មើល​ឲ្យ​ដិត​ដល់​ទៅ​លើ shebang៖ #!/bin/sh.

/bin/sh — វាគ្រាន់តែជា bash symlink ប៉ុណ្ណោះ ដូច្នេះស្គ្រីបត្រូវបានបកស្រាយក្នុងរបៀបដែលឆបគ្នាជាមួយ POSIX មែនទេ? គ្មានផ្លូវទេ! សែលលំនាំដើមនៅក្នុង Debian - វាជាសញ្ញាខ្លីៗ ហើយនោះជាអ្វីដែលវាសម្រាប់ សំដៅទៅ /bin/sh.

# ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Jan 24  2017 /bin/sh -> dash

ជា​ការ​ធ្វើ​តេ​ស្ត​មួយ ខ្ញុំ​បាន​ផ្លាស់​ប្តូ​រ shebang ទៅ #!/bin/bash, បានលុប set -x ហើយព្យាយាមម្តងទៀត។ ទីបំផុត នៅពេលចាប់ផ្តើមឡើងវិញនៃវ៉ានីសជាបន្តបន្ទាប់ កំហុសដែលអាចអត់ឱនបានបានលេចឡើងនៅក្នុងលទ្ធផល៖

Jan 01 12:00:00 hostname varnishreload[32604]: /usr/sbin/varnishreload: line 124: echo: write error: Broken pipe
Jan 01 12:00:00 hostname varnishreload[32604]: VCL 'reload_20190101_120000_32604' compiled

ខ្សែ 124 ហ្នឹងហើយ!

114 find_vcl_file() {
115         VCL_SHOW=$(varnishadm vcl.show -v "$VCL_NAME" 2>&1) || :
116         VCL_FILE=$(
117                 echo "$VCL_SHOW" |
118                 awk '$1 == "//" && $2 == "VCL.SHOW" {print; exit}' | {
119                         # all this ceremony to handle blanks in FILE
120                         read -r DELIM VCL_SHOW INDEX SIZE FILE
121                         echo "$FILE"
122                 }
123         ) || :
124
125         if [ -z "$VCL_FILE" ]
126         then
127                 echo "$VCL_SHOW" >&2
128                 fail "failed to get the VCL file name"
129         fi
130
131         echo "$VCL_FILE"
132 }

ប៉ុន្តែដូចដែលវាប្រែចេញ បន្ទាត់ 124 គឺទទេស្អាត និងគ្មានការចាប់អារម្មណ៍។ ខ្ញុំគ្រាន់តែអាចសន្មត់ថាកំហុសបានកើតឡើងជាផ្នែកនៃខ្សែពហុជួរដែលចាប់ផ្តើមនៅលើបន្ទាត់ 116។
តើអ្វីត្រូវបានសរសេរនៅទីបំផុតទៅអថេរ? VCL_FILE ជាលទ្ធផលនៃការប្រតិបត្តិ sub-shell ខាងលើ?

នៅដើមដំបូងវាបញ្ជូនមាតិកានៃអថេរ VLC_SHOWបង្កើតនៅលើបន្ទាត់ 115 តាមពាក្យបញ្ជាតាមរយៈបំពង់។ ហើយបន្ទាប់មកមានអ្វីកើតឡើងនៅទីនោះ?

ទីមួយវាត្រូវបានគេប្រើនៅទីនោះ varnishadmដែលជាផ្នែកមួយនៃកញ្ចប់ដំឡើងវ៉ារនីស សម្រាប់ការដំឡើងវ៉ារនីសដោយមិនចាប់ផ្តើមឡើងវិញ។

ក្រុមរង vcl.show -v ប្រើដើម្បីបញ្ចេញការកំណត់រចនាសម្ព័ន្ធ VCL ទាំងមូលដែលបានបញ្ជាក់នៅក្នុង ${VCL_NAME}ទៅ STDOUT ។

ដើម្បីបង្ហាញការកំណត់រចនាសម្ព័ន្ធ VCL សកម្មបច្ចុប្បន្ន ក៏ដូចជាកំណែមុនៗជាច្រើននៃការកំណត់រចនាសម្ព័ន្ធផ្លូវវ៉ារនីសដែលនៅតែមាននៅក្នុងសតិ អ្នកអាចប្រើពាក្យបញ្ជា varnishadm vcl.listលទ្ធផល​ដែល​នឹង​ស្រដៀង​គ្នា​នឹង​លទ្ធផល​ខាងក្រោម៖

discarded   cold/busy       1 reload_20190101_120000_11903
discarded   cold/busy       2 reload_20190101_120000_12068
discarded   cold/busy       16 reload_20190101_120000_12259
discarded   cold/busy       16 reload_20190101_120000_12299
discarded   cold/busy       28 reload_20190101_120000_12357
active      auto/warm       32 reload_20190101_120000_12397
available   auto/warm       0 reload_20190101_120000_12587

តម្លៃអថេរ ${VCL_NAME} ត្រូវបានដំឡើងនៅក្នុងផ្នែកផ្សេងទៀតនៃស្គ្រីប varnishreload ទៅឈ្មោះរបស់ VCL ដែលសកម្មបច្ចុប្បន្ន ប្រសិនបើមានមួយ។ ក្នុងករណីនេះវានឹងជា "reload_20190101_120000_12397"។

អស្ចារ្យ, ប្រែប្រួល ${VCL_SHOW} មានការកំណត់រចនាសម្ព័ន្ធពេញលេញសម្រាប់វ៉ារនីស ច្បាស់សម្រាប់ពេលនេះ ឥឡូវ​នេះ​ខ្ញុំ​យល់​ថា​ហេតុ​អ្វី​បាន​ជា​លទ្ធផល​សញ្ញា​ដាច់ set -x ប្រែទៅជាខូចខ្លាំងណាស់ - វារួមបញ្ចូលមាតិកានៃការកំណត់រចនាសម្ព័ន្ធលទ្ធផល។

វាជាការសំខាន់ណាស់ដែលត្រូវយល់ថាការកំណត់រចនាសម្ព័ន្ធ VCL ពេញលេញ ជារឿយៗអាចត្រូវបានផ្សំជាមួយគ្នាពីឯកសារជាច្រើន។ មតិយោបល់រចនាប័ទ្ម C ត្រូវបានប្រើដើម្បីកំណត់កន្លែងដែលឯកសារកំណត់រចនាសម្ព័ន្ធជាក់លាក់ត្រូវបានរួមបញ្ចូលនៅក្នុងឯកសារផ្សេងទៀត ហើយនោះជាអ្វីដែលខ្សែបន្ទាត់នៃកូដខាងក្រោមគឺនិយាយអំពី។
វាក្យសម្ព័ន្ធ​សម្រាប់​មតិ​ដែល​ពិពណ៌នា​អំពី​ឯកសារ​ដែល​បាន​រួម​បញ្ចូល​គឺ​មាន​ទម្រង់​ដូច​ខាង​ក្រោម៖

// VCL.SHOW <NUM> <NUM> <FILENAME>

លេខមិនសំខាន់ក្នុងបរិបទនេះទេ យើងចាប់អារម្មណ៍លើឈ្មោះឯកសារ។

តើមានអ្វីកើតឡើងនៅទីបំផុតនៅក្នុងវាលភក់នៃពាក្យបញ្ជាដែលចាប់ផ្តើមនៅលើបន្ទាត់ 116?
ចូរយើងដោះស្រាយវា។
ក្រុមនេះមានបួនផ្នែក៖

1. សាមញ្ញ echoដែលបោះពុម្ពតម្លៃនៃអថេរ ${VCL_SHOW}

   echo "$VCL_SHOW"

2. awkដែលស្វែងរកបន្ទាត់ (កំណត់ត្រា) ដែលវាលទីមួយបន្ទាប់ពីបំបែកអត្ថបទគឺ "//" ហើយទីពីរគឺ "VCL.SHOW" ។
   Awk នឹងសរសេរចេញនូវបន្ទាត់ទីមួយដែលត្រូវគ្នានឹងលំនាំទាំងនេះ ហើយបន្ទាប់មកឈប់ដំណើរការភ្លាមៗ។

   awk '$1 == "//" && $2 == "VCL.SHOW" {print; exit}'

3. ប្លុក​នៃ​កូដ​ដែល​រក្សាទុក​តម្លៃ​វាល​ជា​អថេរ​ប្រាំ​ដែល​បំបែក​ដោយ​ដកឃ្លា។ អថេរ FILE ទីប្រាំ ទទួលបានបន្ទាត់ដែលនៅសល់។ ជាចុងក្រោយ អេកូចុងក្រោយសរសេរចេញនូវខ្លឹមសារនៃអថេរ ${FILE}.

   { read -r DELIM VCL_SHOW INDEX SIZE FILE; echo "$FILE" }

4. ចាប់តាំងពីជំហានទី 1 ដល់ទី 3 ទាំងអស់ត្រូវបានរុំព័ទ្ធក្នុង subshell មួយ ដោយបញ្ចេញតម្លៃ $FILE នឹងត្រូវបានសរសេរទៅអថេរ VCL_FILE.

ដូចដែលការអត្ថាធិប្បាយនៅលើបន្ទាត់ 119 បានបង្ហាញ នេះបម្រើគោលបំណងតែមួយគត់នៃការដោះស្រាយករណីដែលអាចទុកចិត្តបាន ដែល VCL នឹងយោងឯកសារដែលមានចន្លោះនៅក្នុងឈ្មោះរបស់ពួកគេ។

ខ្ញុំបានអធិប្បាយពីតក្កវិជ្ជាដំណើរការដើមសម្រាប់ ${VCL_FILE} ហើយព្យាយាមផ្លាស់ប្តូរលំដាប់ពាក្យបញ្ជា ប៉ុន្តែវាមិននាំទៅរកអ្វីនោះទេ។ អ្វីៗដំណើរការល្អសម្រាប់ខ្ញុំ ប៉ុន្តែនៅពេលខ្ញុំចាប់ផ្តើមសេវាកម្ម វាបានផ្តល់នូវកំហុស។

វាហាក់បីដូចជាកំហុសមិនអាចបង្កើតឡើងវិញបានទេនៅពេលដំណើរការស្គ្រីបដោយដៃ ខណៈពេលដែល 30 នាទីដែលបានសន្មត់បានផុតកំណត់ចំនួន XNUMX ដងហើយលើសពីនេះ កិច្ចការអាទិភាពខ្ពស់បានលេចឡើងដែលរុញបញ្ហាផ្សេងទៀតមួយឡែក។ នៅសល់នៃសប្តាហ៍នេះត្រូវបានបំពេញដោយភាពខុសគ្នានៃភារកិច្ចហើយត្រូវបានពនឺបន្តិចដោយរបាយការណ៍ស្តីពី sed និងបទសម្ភាសន៍ជាមួយបេក្ខជន។ បញ្ហាជាមួយកំហុសនៅក្នុង varnishreload ត្រូវ​បាន​បាត់​បង់​ដោយ​មិន​អាច​ទាញ​យក​បាន​នៅ​ក្នុង​ខ្សាច់​នៃ​ពេល​វេលា​។

របស់​អ្នក​ដែល​គេ​ហៅ​ថា sed-fu... គឺ​ពិត​ជា... សំរាម

នៅសប្តាហ៍បន្ទាប់ខ្ញុំមានថ្ងៃទំនេរមួយ ដូច្នេះខ្ញុំសម្រេចចិត្តដោះស្រាយសំបុត្រនេះម្តងទៀត។ ខ្ញុំសង្ឃឹមថានៅក្នុងខួរក្បាលរបស់ខ្ញុំ ដំណើរការផ្ទៃខាងក្រោយមួយចំនួនបានកំពុងស្វែងរកដំណោះស្រាយចំពោះបញ្ហានេះគ្រប់ពេល ហើយលើកនេះខ្ញុំច្បាស់ជាយល់អំពីអ្វីដែលកំពុងកើតឡើង។

ដោយសារការផ្លាស់ប្តូរលេខកូដមិនអាចជួយបានកាលពីលើកមុន ខ្ញុំទើបតែសម្រេចចិត្តសរសេរវាឡើងវិញដោយចាប់ផ្តើមពីបន្ទាត់ 116។ ក្នុងករណីណាក៏ដោយលេខកូដដែលមានស្រាប់គឺឆោតល្ងង់។ ហើយពិតជាមិនចាំបាច់ប្រើវាទេ។ read.

មើលកំហុសម្តងទៀត៖
sh: echo: broken pipe - បន្ទរលេចឡើងជាពីរកន្លែងនៅក្នុងពាក្យបញ្ជានេះ ប៉ុន្តែខ្ញុំសង្ស័យថា ទីមួយគឺជាពិរុទ្ធជនដែលទំនងជាង (ឬយ៉ាងហោចណាស់អ្នកសមគំនិត)។ Awk ក៏មិនជម្រុញទំនុកចិត្តដែរ។ ហើយក្នុងករណីដែលវាពិតជា awk | {read; echo} ការរចនានាំឱ្យមានបញ្ហាទាំងអស់នេះ ហេតុអ្វីមិនជំនួសវា? ពាក្យបញ្ជាមួយបន្ទាត់នេះមិនប្រើលក្ខណៈពិសេសទាំងអស់របស់ awk ទេ ហើយសូម្បីតែពាក្យបញ្ជាបន្ថែមនេះក៏ដោយ។ read លើស​ពី​នេះ​ទៀត។

ចាប់តាំងពីសប្តាហ៍មុន មានរបាយការណ៍ស្តីពី sedខ្ញុំចង់សាកល្បងជំនាញដែលទើបទទួលបានថ្មីរបស់ខ្ញុំ និងធ្វើឱ្យងាយស្រួល echo | awk | { read; echo} ចូលទៅក្នុងការយល់កាន់តែច្បាស់ echo | sed. ខណៈពេលដែលនេះមិនមែនជាវិធីសាស្រ្តដ៏ល្អបំផុតក្នុងការកំណត់អត្តសញ្ញាណកំហុស ខ្ញុំគិតថាយ៉ាងហោចណាស់ខ្ញុំនឹងសាកល្បង sed-fu របស់ខ្ញុំ ហើយប្រហែលជារៀនអ្វីថ្មីអំពីបញ្ហា។ នៅតាមផ្លូវ ខ្ញុំបានសុំមិត្តរួមការងាររបស់ខ្ញុំ ដែលជាអ្នកនិពន្ធនៃ sed talk ដើម្បីជួយខ្ញុំបង្កើតអក្សរ sed ដែលមានប្រសិទ្ធភាពជាងមុន។

ខ្ញុំបានទម្លាក់មាតិកា varnishadm vcl.show -v "$VCL_NAME" ទៅកាន់ឯកសារ ដូច្នេះខ្ញុំអាចផ្តោតលើការសរសេរស្គ្រីប sed ដោយមិនមានបញ្ហាក្នុងការចាប់ផ្តើមឡើងវិញនូវសេវាកម្ម។

ការពិពណ៌នាខ្លីៗអំពីរបៀបដែលការបញ្ចូលដំណើរការ sed អាចត្រូវបានរកឃើញនៅក្នុង សៀវភៅណែនាំ GNU របស់គាត់។. នៅក្នុងប្រភព sed និមិត្តសញ្ញា n បញ្ជាក់យ៉ាងច្បាស់ថាជាសញ្ញាបំបែកបន្ទាត់។

នៅក្នុងការឆ្លងកាត់ជាច្រើន និងជាមួយនឹងអនុសាសន៍របស់សហសេវិករបស់ខ្ញុំ យើងបានសរសេរស្គ្រីប sed ដែលផ្តល់លទ្ធផលដូចគ្នានឹងបន្ទាត់ដើមទាំងមូល 116 ។

ខាងក្រោមនេះជាឯកសារគំរូដែលមានទិន្នន័យបញ្ចូល៖

> cat vcl-example.vcl
Text
// VCL.SHOW 0 1578 file with 3 spaces.vcl
More text
// VCL.SHOW 0 1578 file.vcl
Even more text
// VCL.SHOW 0 1578 file with TWOspaces.vcl
Final text

នេះប្រហែលជាមិនច្បាស់ពីការពិពណ៌នាខាងលើទេ ប៉ុន្តែយើងគ្រាន់តែចាប់អារម្មណ៍លើមតិយោបល់ដំបូងប៉ុណ្ណោះ។ // VCL.SHOWហើយវាអាចមានពួកវាជាច្រើននៅក្នុងទិន្នន័យបញ្ចូល។ នេះ​ជា​មូល​ហេតុ​ដែល​ការ​ប្រកួត​ដើម​បញ្ចប់​បន្ទាប់​ពី​ការ​ប្រកួត​ដំបូង។

# шаг первый, вывести только строки с комментариями
# используя возможности sed, определяется символ-разделитель с помощью конструкции '#' вместо обычно используемого '/', за счёт этого не придётся экранировать косые в искомом комментарии
# определяется регулярное выражение “// VCL.SHOW”, для поиска строк с определенным шаблоном
# флаг -n позаботится о том, чтобы sed не выводил все входные данные, как он это делает по умолчанию (см. ссылку выше)
# -E позволяет использовать расширенные регулярные выражения
> cat vcl-processor-1.sed
#// VCL.SHOW#p
> sed -En -f vcl-processor-1.sed vcl-example.vcl
// VCL.SHOW 0 1578 file with 3 spaces.vcl
// VCL.SHOW 0 1578 file.vcl
// VCL.SHOW 0 1578 file with TWOspaces.vcl

# шаг второй, вывести только имя файла
# используя команду “substitute”, с группами внутри регулярных выражений, отображается только нужная группa
# и это делается только для совпадений, ранее описанного поиска
> cat vcl-processor-2.sed
#// VCL.SHOW# {
    s#.* [0-9]+ [0-9]+ (.*)$#1#
    p
}
> sed -En -f vcl-processor-2.sed vcl-example.vcl
file with 3 spaces.vcl
file.vcl
file with TWOspaces.vcl

# шаг третий, получить только первый из результатов
# как и в случае с awk, добавляется немедленное завершения после печати первого найденного совпадения
> cat vcl-processor-3.sed
#// VCL.SHOW# {
    s#.* [0-9]+ [0-9]+ (.*)$#1#
    p
    q
}
> sed -En -f vcl-processor-3.sed vcl-example.vcl
file with 3 spaces.vcl

# шаг четвертый, схлопнуть всё в однострочник, используя двоеточия для разделения команд
> sed -En -e '#// VCL.SHOW#{s#.* [0-9]+ [0-9]+ (.*)$#1#p;q;}' vcl-example.vcl
file with 3 spaces.vcl

ដូច្នេះមាតិកានៃស្គ្រីប varnishreload នឹងមើលទៅដូចនេះ:

VCL_FILE="$(echo "$VCL_SHOW" | sed -En '#// VCL.SHOW#{s#.*[0-9]+ [0-9]+ (.*)$#1#p;q;};')"

តក្កវិជ្ជាខាងលើអាចបង្ហាញយ៉ាងខ្លីដូចខាងក្រោមៈ
ប្រសិនបើខ្សែអក្សរត្រូវគ្នានឹងកន្សោមធម្មតា។ // VCL.SHOWបន្ទាប់មក លោភលន់លេបអត្ថបទដែលមានទាំងលេខនៅក្នុងបន្ទាត់នេះ ហើយរក្សាទុកអ្វីគ្រប់យ៉ាងដែលនៅសេសសល់បន្ទាប់ពីប្រតិបត្តិការនេះ។ បញ្ចេញតម្លៃដែលបានរក្សាទុក ហើយបញ្ចប់កម្មវិធី។

សាមញ្ញណាស់មែនទេ?

យើងសប្បាយចិត្តជាមួយនឹងស្គ្រីប sed និងការពិតដែលថាវាបានជំនួសលេខកូដដើមទាំងអស់។ រាល់ការធ្វើតេស្តរបស់ខ្ញុំបានផ្តល់លទ្ធផលដែលចង់បាន ដូច្នេះខ្ញុំបានប្តូរ "varnishreload" នៅលើម៉ាស៊ីនមេ ហើយដំណើរការវាម្តងទៀត systemctl reload varnish. កំហុសមិនល្អ echo: write error: Broken pipe សើចនៅមុខយើងម្តងទៀត។ ទស្សន៍ទ្រនិច​ដែល​កំពុង​តែ​រង់​ចាំ​ពាក្យ​បញ្ជា​ថ្មី​ត្រូវ​បាន​បញ្ចូល​ក្នុង​ភាព​ងងឹត​នៃ​ស្ថានីយ...

ប្រភព: www.habr.com