كتيبات سطر الأوامر

Man » دليل patch عبر الإنترنت - وثائق مفصلة عبر الإنترنت لصفحة دليل patch

🌍
patch - تطبيق ملف اختلاف على ملف أصلي

ملخص

patch [خيارات] [الملف_الأصلي [ملف_الاختلاف]]

ولكن عادةً ما يكون الأمر:

patch -pnum <ملف_الاختلاف>

الوصف

يأخذ الأمر patch ملف اختلاف، يسمى ملف_الاختلاف، يحتوي على قائمة اختلافات تم إنشاؤها بواسطة برنامج diff، ويطبق هذه الاختلافات على ملف أو أكثر من الملفات الأصلية، وينتج نسخًا معدلة. عادةً ما يتم وضع النسخ المعدلة محل النسخ الأصلية. يمكن إنشاء نسخ احتياطية؛ انظر خيار -b أو --backup. يتم عادةً أخذ أسماء الملفات المراد تعديلها من ملف الاختلاف، ولكن إذا كان هناك ملف واحد فقط للتعديل، فيمكن تحديده في سطر الأوامر كـ ملف_أصلي.

عند بدء التشغيل، يحاول الأمر patch تحديد نوع قائمة الاختلاف، ما لم يتم تجاوز ذلك بواسطة خيار -c (--context)، أو -e (--ed)، أو -n (--normal)، أو -u (--unified). يتم تطبيق الاختلافات السياقية (القديمة والجديدة والموحدة) والاختلافات العادية بواسطة برنامج patch نفسه، بينما يتم ببساطة إرسال الاختلافات بنمط ed إلى محرر ed(1) عبر قناة.

يحاول الأمر patch تخطي أي بيانات غير ضرورية في البداية، وتطبيق الاختلاف، ثم تخطي أي بيانات غير ضرورية في النهاية. وبالتالي، يمكنك إدخال رسالة بريد إلكتروني تحتوي على قائمة اختلافات إلى الأمر patch، فيجب أن يعمل. إذا كان الاختلاف بأكمله مُزاحًا بمقدار ثابت، أو إذا كانت الأسطر تنتهي بـ CRLF، أو إذا تم تغليف الاختلاف مرة واحدة أو أكثر عن طريق إضافة "- " إلى الأسطر التي تبدأ بـ "- " كما هو محدد في RFC 934، يتم أخذ ذلك في الاعتبار. بعد إزالة الإزاحة أو التغليف، يتم تجاهل الأسطر التي تبدأ بـ #، حيث تعتبر تعليقات.

بالنسبة للاختلافات السياقية، وإلى حد ما بالنسبة للاختلافات العادية، يمكن لـ patch اكتشاف متى تكون أرقام الأسطر المذكورة في التصحيح غير صحيحة، ويحاول العثور على المكان الصحيح لتطبيق كل جزء من التصحيح. كتخمين أولي، يأخذ رقم السطر المذكور للجزء، بالإضافة إلى أو طرح أي إزاحة مستخدمة في تطبيق الجزء السابق. إذا لم يكن هذا هو المكان الصحيح، يقوم الأمر patch بمسح للأمام والخلف بحثًا عن مجموعة من الأسطر التي تتطابق مع السياق المحدد في الجزء. أولاً، يبحث الأمر patch عن مكان تتطابق فيه جميع أسطر السياق. إذا لم يتم العثور على مثل هذا المكان، وإذا كان اختلافًا سياقيًا، وكان الحد الأقصى لعامل التراخي (fuzz factor) مضبوطًا على 1 أو أكثر، فإنه يتم إجراء مسح آخر مع تجاهل السطر الأول والأخير من السياق. إذا فشل ذلك، وكان الحد الأقصى لعامل التراخي مضبوطًا على 2 أو أكثر، فسيتم تجاهل السطرين الأولين والأخيرين من السياق، ويتم إجراء مسح آخر. (الافتراضي للحد الأقصى لعامل التراخي هو 2).

يجب أن يتم تطبيق الأجزاء التي تحتوي على سياق بادئة أقل من سياق لاحق (بعد تطبيق التراخي) في بداية الملف إذا كان السطر الأول هو 1. يجب أن يتم تطبيق الأجزاء التي تحتوي على سياق بادئة أكثر من سياق لاحق (بعد تطبيق التراخي) في نهاية الملف.

إذا لم يتمكن برنامج التصحيح من العثور على مكان لتثبيت جزء معين من التصحيح، فإنه يضع هذا الجزء في ملف "مرفوض" (reject file)، والذي يكون اسمه عادةً اسم ملف الإخراج مضافًا إليه لاحقة ".rej"، أو "#" إذا كان إضافة ".rej" سينتج عنه اسم ملف طويل جدًا (إذا كان حتى إضافة الحرف الواحد "#" يجعل اسم الملف طويلاً جدًا، فسيتم استبدال الحرف الأخير من اسم الملف بـ "#").

يظهر الجزء المرفوض بتنسيق "diff" موحد أو سياقي. إذا كان الإدخال عبارة عن "diff" عادي، فإن العديد من السياقات تكون فارغة. قد تكون أرقام الأسطر في الأجزاء الموجودة في ملف "المرفوض" مختلفة عن تلك الموجودة في ملف التصحيح: فهي تعكس الموقع التقريبي الذي يعتقد برنامج التصحيح أن الأجزاء الفاشلة يجب أن توضع فيه في الملف الجديد بدلاً من الملف القديم.

عند اكتمال كل جزء، يتم إخبارك إذا فشل هذا الجزء، وإذا كان الأمر كذلك، فسيتم إخبارك بالسطر (في الملف الجديد) الذي اعتقد برنامج التصحيح أنه يجب وضع الجزء فيه. إذا تم تثبيت الجزء في سطر مختلف عن رقم السطر المحدد في "diff"، فسيتم إخبارك بالإزاحة. قد يشير الإزاحة الكبيرة إلى أن الجزء تم تثبيته في المكان الخطأ. يتم إخبارك أيضًا إذا تم استخدام عامل "التشويش" لإجراء المطابقة، وفي هذه الحالة يجب أن تكون حذرًا بعض الشيء. إذا تم إعطاء خيار "--verbose"، فسيتم إخبارك أيضًا بالأجزاء التي تطابق تمامًا.

إذا لم يتم تحديد ملف أصلي (origfile) في سطر الأوامر، يحاول برنامج التصحيح معرفة اسم الملف المراد تحريره من "البيانات غير المرغوب فيها" في البداية، باستخدام القواعد التالية.

أولاً، يأخذ برنامج التصحيح قائمة مرتبة من أسماء الملفات المرشحة على النحو التالي:

إذا كان الرأس هو رأس "diff" سياقي، يأخذ برنامج التصحيح أسماء الملفات القديمة والجديدة في الرأس. يتم تجاهل الاسم إذا لم يكن لديه عدد كافٍ من الشرطات (slashes) لتلبية الخيار "-pnum" أو "--strip=num". يتم أيضًا تجاهل الاسم "/dev/null".

إذا كان هناك سطر "Index:" في "البيانات غير المرغوب فيها" وإذا كان كل من الأسماء القديمة والجديدة غائبين أو إذا كان برنامج التصحيح متوافقًا مع معيار POSIX، فيأخذ برنامج التصحيح الاسم الموجود في سطر "Index:".

لأغراض القواعد التالية، يتم اعتبار أسماء الملفات المرشحة بترتيب (قديم، جديد، فهرس)، بغض النظر عن الترتيب الذي تظهر به في الرأس.

ثم يختار برنامج التصحيح اسم ملف من القائمة المرشحة على النحو التالي:

إذا كان بعض الملفات المسماة موجودة، يختار برنامج التصحيح الاسم الأول إذا كان متوافقًا مع معيار POSIX، والاسم "الأفضل" بخلاف ذلك.

إذا لم يكن برنامج التصحيح يتجاهل أنظمة RCS و ClearCase و Perforce و SCCS (انظر الخيار "-g num" أو "--get=num")، ولم تكن أي من الملفات المسماة موجودة ولكن تم العثور على ملف رئيسي لنظام RCS أو ClearCase أو Perforce أو SCCS، فيختار برنامج التصحيح أول اسم ملف يحتوي على ملف رئيسي لنظام RCS أو ClearCase أو Perforce أو SCCS.

إذا لم تكن أي من الملفات المسماة موجودة، ولم يتم العثور على أي ملف رئيسي لأنظمة RCS أو ClearCase أو Perforce أو SCCS، وتم إعطاء بعض الأسماء، ولم يكن برنامج التصحيح متوافقًا مع معيار POSIX، ويبدو أن التصحيح سيقوم بإنشاء ملف، فيختار برنامج التصحيح الاسم الأفضل الذي يتطلب إنشاء أقل عدد من الدلائل.


إذا لم ينتج عن العمليات المذكورة أعلاه اسم ملف، فسيُطلب منك اسم الملف الذي سيتم تصحيحه، وسيقوم patch بتحديد هذا الاسم.

لتحديد أفضل اسم ملف من قائمة غير فارغة، يبدأ patch بأخذ جميع الأسماء التي تحتوي على أقل عدد من مكونات مسار الملف؛ ومن بين هذه، يأخذ جميع الأسماء ذات أقصر اسم قاعدة؛ ومن بين هذه، يأخذ جميع الأسماء الأقصر؛ وأخيرًا، يأخذ الاسم الأول المتبقي.

بالإضافة إلى ذلك، إذا كان الجزء الأول من الملف يحتوي على سطر Prereq:‎، فسيأخذ patch الكلمة الأولى من سطر المتطلبات (عادةً ما يكون رقم إصدار) ويتحقق من الملف الأصلي لمعرفة ما إذا كان يمكن العثور على هذه الكلمة. إذا لم يتم العثور عليها، يطلب patch التأكيد قبل المتابعة.

الخلاصة من كل هذا هي أنه يجب أن تكون قادرًا على تشغيل أمر shell مثل التالي:

    patch -d /usr/src/local/blurfl

وتطبيق ملف في دليل blurfl مباشرةً من ملف تصحيح تتم قراءته من الإدخال القياسي.

إذا كان ملف التصحيح يحتوي على أكثر من تصحيح واحد، يحاول patch تطبيق كل منها كما لو كانت من ملفات تصحيح منفصلة. وهذا يعني، من بين أمور أخرى، أنه من المفترض تحديد اسم الملف الذي سيتم تصحيحه لكل قائمة بالفرق، وأن الجزء الأول من كل قائمة بالفرق يحتوي على معلومات مهمة مثل أسماء الملفات ومستوى المراجعة، كما هو مذكور سابقًا.

الخيارات

-b أو --backup
قم بإنشاء ملفات نسخ احتياطية. أي أنه عند تصحيح ملف، قم بإعادة تسمية أو نسخ الملف الأصلي بدلاً من حذفه. راجع خيار `-V` أو `--version-control` للحصول على تفاصيل حول كيفية تحديد أسماء ملفات النسخ الاحتياطي.

--backup-if-mismatch
قم بعمل نسخة احتياطية من ملف إذا لم يتطابق التصحيح مع الملف تمامًا وإذا لم يتم طلب النسخ الاحتياطي بطريقة أخرى. هذا هو الإعداد الافتراضي ما لم يكن `patch` متوافقًا مع معيار POSIX.

--no-backup-if-mismatch
لا تقم بعمل نسخة احتياطية من ملف إذا لم يتطابق التصحيح مع الملف تمامًا وإذا لم يتم طلب النسخ الاحتياطي بطريقة أخرى. هذا هو الإعداد الافتراضي إذا كان `patch` متوافقًا مع معيار POSIX.

-B pref أو --prefix=pref
استخدم الطريقة البسيطة لتحديد أسماء ملفات النسخ الاحتياطي (راجع خيار `-V` أو `--version-control`)، وأضف `pref` إلى اسم الملف عند إنشاء اسم ملف النسخ الاحتياطي الخاص به. على سبيل المثال، مع الخيار `-B /junk/‎`، سيكون اسم ملف النسخ الاحتياطي البسيط للملف `src/patch/util.c` هو `/junk/src/patch/util.c`.

--binary
اكتب جميع الملفات في الوضع الثنائي، باستثناء الإخراج القياسي و `/dev/tty`. عند القراءة، قم بتعطيل الاستدلال لتحويل نهايات الأسطر `CRLF` إلى نهايات الأسطر `LF`. هذا الخيار مطلوب على أنظمة POSIX عند تطبيق التصحيحات التي تم إنشاؤها على أنظمة غير POSIX على ملفات غير POSIX. (على أنظمة POSIX، لا تقوم عمليات القراءة والكتابة للملفات أبدًا بتحويل نهايات الأسطر. على نظام التشغيل Windows، تقوم عمليات القراءة والكتابة بتحويل نهايات الأسطر افتراضيًا، ويجب إنشاء التصحيحات بواسطة `diff --binary` عندما تكون نهايات الأسطر ذات أهمية.)

-c أو --context
فسّر ملف التصحيح كتصحيح سياقي عادي.

-d dir أو --directory=dir
انتقل إلى الدليل `dir` على الفور، قبل فعل أي شيء آخر.

-D define  أو  --ifdef=define

استخدم الصيغة #ifdef ... #endif لتمييز التغييرات، مع define كرمز مميز.

--dry-run

اطبع نتائج تطبيق التصحيحات دون تغيير أي ملفات فعليًا.

-e  أو  --ed

فسر ملف التصحيح على أنه سكريبت ed.

-E  أو  --remove-empty-files

أزل ملفات الإخراج التي تكون فارغة بعد تطبيق التصحيحات. عادةً ما يكون هذا الخيار غير ضروري، حيث يمكن لـ patch فحص الطوابع الزمنية في الترويسة لتحديد ما إذا كان يجب أن يكون الملف موجودًا بعد التصحيح. ومع ذلك، إذا لم يكن الإدخال بصيغة context diff أو إذا كان patch متوافقًا مع POSIX، لا يزيل patch الملفات المصححة الفارغة ما لم يُعطَ هذا الخيار. عندما يزيل patch ملفًا، فإنه يحاول أيضًا إزالة أي أدلة أصل فارغة.

-f  أو  --force

افترض أن المستخدم يعرف بالضبط ما يفعله، ولا تسأل أي أسئلة. تخطَّ التصحيحات التي لا تذكر ترويستها أي ملف يجب تصحيحه؛ صحح الملفات حتى لو كان لديها الإصدار الخاطئ لسطر Prereq: في التصحيح؛ وافترض أن التصحيحات ليست معكوسة حتى لو بدت كذلك. هذا الخيار لا يكبت التعليقات؛ استخدم -s لهذا الغرض.

-F num  أو  --fuzz=num

اضبط أقصى معامل تشوش. ينطبق هذا الخيار فقط على ملفات diffs التي تحتوي على سياق، ويجعل patch يتجاهل ما يصل إلى هذا العدد من أسطر السياق عند البحث عن أماكن لتثبيت جزء. لاحظ أن معامل تشوش أكبر يزيد من احتمالات التصحيح الخاطئ. معامل التشوش الافتراضي هو 2. معامل تشوش أكبر من أو يساوي عدد أسطر السياق في context diff، عادةً 3، يتجاهل كل السياق.

-g num  أو  --get=num

يتحكم هذا الخيار في إجراءات patch عندما يكون الملف تحت تحكم RCS أو SCCS، ولا يكون موجودًا أو للقراءة فقط ويطابق الإصدار الافتراضي، أو عندما يكون الملف تحت تحكم ClearCase أو Perforce ولا يكون موجودًا. إذا كان num موجبًا، يحصل patch على (أو يسحب) الملف من نظام تحكم المراجعة؛ إذا كان صفرًا، يتجاهل patch أنظمة RCS و ClearCase و Perforce و SCCS ولا يحصل على الملف؛ وإذا كان سالبًا، يسأل patch المستخدم ما إذا كان سيحصل على الملف. القيمة الافتراضية لهذا الخيار معطاة بقيمة متغير البيئة PATCH_GET إذا تم تعيينه؛ وإذا لم يكن، فالقيمة الافتراضية هي صفر.

--help

اطبع ملخصًا للخيارات واخرج.

-i ملف_التصحيح  أو  --input=ملف_التصحيح

اقرأ التصحيح من ملف_التصحيح. إذا كان ملف_التصحيح هو -، اقرأ من المدخل القياسي، وهو الافتراضي.

-l  أو  --ignore-whitespace

طابق الأنماط بشكل غير محكم، في حال تم العبث بعلامات الجدولة أو المسافات في ملفاتك. أي تسلسل من مسافة واحدة أو أكثر في ملف التصحيح يطابق أي تسلسل في الملف الأصلي، ويتم تجاهل تسلسلات المسافات في نهايات الأسطر. يجب أن تظل الأحرف العادية متطابقة تمامًا. كل سطر من السياق يجب أن يظل مطابقًا لسطر في الملف الأصلي.

--merge أو --merge=merge أو --merge=diff3

ادمج ملف تصحيح في الملفات الأصلية بشكل مشابه لـ diff3(1) أو merge(1). إذا تم العثور على تعارض، يُخرج patch تحذيرًا ويضع التعارض بين سطري <<<<<<< و >>>>>>>. سيبدو التعارض النموذجي هكذا:


<<<<<<<
الأسطر من الملف الأصلي
|||||||
الأسطر الأصلية من التصحيح
=======
الأسطر الجديدة من التصحيح
>>>>>>>

تحدد الوسيطة الاختيارية لـ `--merge` تنسيق الإخراج للتضارب: يعرض تنسيق `diff3` قسم `|||||||` بالأسطر الأصلية من التصحيح؛ في تنسيق `merge`، يفتقد هذا القسم. تنسيق `merge` هو الافتراضي.

تتضمن هذه الخيار `--forward` ولا تأخذ في الاعتبار الخيار `--fuzz=num`.

-n أو `--normal`
اعتبر ملف التصحيح كملف تصحيح عادي.

-N أو `--forward`
عندما لا يتم تطبيق التصحيح، يتحقق برنامج `patch` عادةً مما إذا كان التصحيح قد تم تطبيقه بالفعل عن طريق محاولة عكس تطبيق أول مجموعة. يمنع الخيار `--forward` ذلك. انظر أيضًا `-R`.

-o outfile أو `--output=outfile`
أرسل الإخراج إلى `outfile` بدلاً من تصحيح الملفات في مكانها. لا تستخدم هذا الخيار إذا كان `outfile` أحد الملفات المراد تصحيحها. عندما يكون `outfile` هو `-`، أرسل الإخراج إلى الإخراج القياسي، وأرسل أي رسائل كان سيتم إرسالها عادةً إلى الإخراج القياسي إلى الخطأ القياسي.

-pnum أو `--strip=num`
قم بإزالة أصغر بادئة تحتوي على `num` من الشرطات المائلة الرائدة من كل اسم ملف موجود في ملف التصحيح. يتم اعتبار تسلسل واحد أو أكثر من الشرطات المائلة المتجاورة شرطة مائلة واحدة. يتحكم هذا في كيفية التعامل مع أسماء الملفات الموجودة في ملف التصحيح، في حالة الاحتفاظ بملفاتك في دليل مختلف عن الشخص الذي أرسل التصحيح. على سبيل المثال، بافتراض أن اسم الملف في ملف التصحيح هو:

/u/howard/src/blurfl/blurfl.c

فإن تعيين `-p0` يعطي اسم الملف الكامل دون تعديل، `-p1` يعطي:

u/howard/src/blurfl/blurfl.c

بدون الشرطة المائلة الرائدة، `-p4` يعطي:

blurfl/blurfl.c

وعدم تحديد `-p` يعطيك ببساطة `blurfl.c`. يتم البحث عن أي من هذه النتائج إما في الدليل الحالي، أو في الدليل المحدد بواسطة الخيار `-d`.

--posix
الالتزام بشكل أكثر صرامة بمعيار POSIX، على النحو التالي:

خذ أول ملف موجود من القائمة (قديم، جديد، فهرس) عند تخمين أسماء الملفات من رؤوس `diff`.

لا تقم بإزالة الملفات التي تكون فارغة بعد التصحيح.

لا تسأل عما إذا كنت تريد الحصول على ملفات من RCS أو ClearCase أو Perforce أو SCCS.

تتطلب أن تكون جميع الخيارات قبل الملفات في سطر الأوامر.

لا تقم بعمل نسخة احتياطية من الملفات في حالة وجود عدم تطابق.

--quoting-style=word
استخدم النمط `word` لعمل اقتباس لأسماء الإخراج. يجب أن تكون الكلمة واحدة من الكلمات التالية:

literal
إخراج الأسماء كما هي.

shell
اقتبس الأسماء لـ shell إذا كانت تحتوي على أحرف shell خاصة أو من شأنها أن تتسبب في إخراج غامض.

shell-always
اقتبس الأسماء لـ shell، حتى لو لم تكن تتطلب اقتباسًا بشكل طبيعي.

c
اقتبس الأسماء كما هو الحال في سلسلة لغة C.

escape
اقتبس كما هو الحال مع `c` باستثناء حذف أحرف علامات الاقتباس المزدوجة المحيطة.

يمكنك تحديد القيمة الافتراضية لخيار `--quoting-style` باستخدام متغير البيئة `QUOTING_STYLE`. إذا لم يتم تعيين متغير البيئة هذا، فإن القيمة الافتراضية هي `shell`.

-r rejectfile أو --reject-file=rejectfile

ضع الرفضات في ملف rejectfile بدلاً من ملف .rej الافتراضي. عندما يكون rejectfile هو -، تجاهل الرفضات.

-R أو --reverse

افترض أن هذا التصحيح تم إنشاؤه مع تبديل الملفين القديم والجديد. (نعم، أنا أخشى أن يحدث ذلك في بعض الأحيان، فالطبيعة البشرية هي ما هي). يحاول التصحيح تبديل كل جزء قبل تطبيقه. تظهر الرفضات بالتنسيق المبدل. لا يعمل خيار -R مع نصوص ed diff لأنه لا يوجد ما يكفي من المعلومات لإعادة بناء العملية العكسية.

إذا فشل الجزء الأول من التصحيح، يقوم التصحيح بعكس الجزء لمعرفة ما إذا كان يمكن تطبيقه بهذه الطريقة. إذا كان الأمر كذلك، يُطلب منك ما إذا كنت تريد تعيين خيار -R. إذا لم يكن الأمر كذلك، يستمر التصحيح في التطبيق بشكل طبيعي. (ملاحظة: لا يمكن لهذه الطريقة اكتشاف التصحيح المعكوس إذا كان تصحيحًا عاديًا وإذا كانت التعليمة الأولى عبارة عن إلحاق (أي يجب أن تكون حذفًا) نظرًا لأن عمليات الإلحاق تنجح دائمًا، بسبب حقيقة أن السياق الفارغ يتطابق في أي مكان. لحسن الحظ، تضيف معظم التصحيحات أو تغير الأسطر بدلاً من حذفها، لذلك تبدأ معظم التصحيحات العادية المعكوسة بحذف، والذي يفشل، مما يؤدي إلى تشغيل الاستدلال).

--read-only=behavior

تصرف كما هو مطلوب عند محاولة تعديل ملف للقراءة فقط: تجاهل المشكلة المحتملة، أو حذر بشأنها (افتراضيًا)، أو فشل.

--reject-format=format

قم بإنشاء ملفات الرفض بالتنسيق المحدد (إما سياقي أو موحد). بدون هذا الخيار، تظهر الأجزاء المرفوضة بتنسيق الفرق الموحد إذا كان التصحيح المدخل بهذا التنسيق، وإلا في تنسيق الفرق السياقي العادي.

-s أو --silent أو --quiet

اعمل بصمت، إلا إذا حدث خطأ.

--follow-symlinks

عند البحث عن الملفات المدخلة، اتبع الروابط الرمزية. استبدل الروابط الرمزية، بدلاً من تعديل الملفات التي تشير إليها الروابط الرمزية. لن يتم تطبيق التصحيحات بأسلوب Git على الروابط الرمزية. يوجد هذا الخيار للتوافق مع الإصدارات السابقة من التصحيح؛ لا يُنصح باستخدامه.

-t أو --batch

قم بإخماد الأسئلة مثل -f، ولكن قدم بعض الافتراضات المختلفة: تخطى التصحيحات التي لا تحتوي رؤوسها على أسماء ملفات (نفس -f)؛ تخطى التصحيحات التي يكون للملف بها إصدار خاطئ لسطر Prereq: في التصحيح؛ وافترض أن التصحيحات معكوسة إذا بدا أنها كذلك.

-T أو --set-time

قم بتعيين أوقات التعديل والوصول للملفات التي تم تصحيحها من الطوابع الزمنية الموجودة في رؤوس الفرق السياقية. ما لم يتم تحديدها في الطوابع الزمنية، افترض أن رؤوس الفرق السياقية تستخدم التوقيت المحلي.

لا يُنصح باستخدام هذا الخيار مع الطوابع الزمنية التي لا تتضمن مناطق زمنية، لأن التصحيحات التي تستخدم التوقيت المحلي لا يمكن استخدامها بسهولة من قبل الأشخاص في مناطق زمنية أخرى، ولأن الطوابع الزمنية المحلية غامضة عندما تتحرك الساعات المحلية للخلف أثناء تعديلات التوقيت الصيفي. تأكد من أن الطوابع الزمنية تتضمن مناطق زمنية، أو قم بإنشاء تصحيحات باستخدام UTC واستخدم الخيار -Z أو --set-utc بدلاً من ذلك.


-u أو --unified
فسّر ملف التصحيح على أنه تصحيح سياقي موحد.

-v أو --version
اطبع رأس مراجعة التصحيح ومستوى التصحيح، ثم اخرج.

-V method أو --version-control=method
استخدم method لتحديد أسماء ملفات النسخ الاحتياطي. يمكن أيضًا تحديد method عن طريق متغير البيئة PATCH_VERSION_CONTROL (أو، إذا لم يتم تعيين ذلك، فإن متغير البيئة VERSION_CONTROL)، والذي يتم تجاوزه بواسطة هذا الخيار. لا يؤثر method على ما إذا تم إنشاء ملفات نسخ احتياطي أم لا؛ بل يؤثر فقط على أسماء أي ملفات نسخ احتياطي يتم إنشاؤها.

قيمة method مشابهة لمتغير التحكم في الإصدار في GNU Emacs؛ كما يتعرف patch على المرادفات الأكثر وصفًا. القيم الصالحة لـ method هي (تُقبل الاختصارات الفريدة):

existing أو nil
قم بإنشاء نسخ احتياطية مرقمة للملفات التي تحتوي بالفعل عليها، وإلا قم بإنشاء نسخ احتياطية بسيطة. هذا هو الإعداد الافتراضي.

numbered أو t
قم بإنشاء نسخ احتياطية مرقمة. اسم ملف النسخ الاحتياطي المرقم للملف F هو F.~N~ حيث N هو رقم الإصدار.

simple أو never
قم بإنشاء نسخ احتياطية بسيطة. تحدد الخيارات -B أو --prefix، و -Y أو --basename-prefix، و -z أو --suffix اسم ملف النسخ الاحتياطي البسيط. إذا لم يتم تقديم أي من هذه الخيارات، فسيتم استخدام لاحقة النسخ الاحتياطي البسيط؛ وهي قيمة متغير البيئة SIMPLE_BACKUP_SUFFIX إذا تم تعيينه، وإلا فستكون .orig.

مع النسخ الاحتياطية المرقمة أو البسيطة، إذا كان اسم ملف النسخ الاحتياطي طويلاً جدًا، فسيتم استخدام لاحقة النسخ الاحتياطي ~ بدلاً من ذلك؛ وإذا كان حتى إضافة ~ سيجعل الاسم طويلاً جدًا، فسيتم استبدال ~ بالحرف الأخير من اسم الملف.

--verbose
أخرج معلومات إضافية حول العمل الذي يتم إجراؤه.

-x num أو --debug=num
عيّن علامات التصحيح الداخلية التي تهم فقط مبرمجي patch.

-Y pref أو --basename-prefix=pref
استخدم الطريقة البسيطة لتحديد أسماء ملفات النسخ الاحتياطي (انظر الخيار -V method أو --version-control method)، وأضف البادئة pref إلى اسم الملف الأساسي عند إنشاء اسم ملف النسخ الاحتياطي الخاص به. على سبيل المثال، باستخدام -Y .del/، سيكون اسم ملف النسخ الاحتياطي البسيط لـ src/patch/util.c هو src/patch/.del/util.c.

-z suffix أو --suffix=suffix
استخدم الطريقة البسيطة لتحديد أسماء ملفات النسخ الاحتياطي (انظر الخيار -V method أو --version-control method)، واستخدم suffix كلاحقة. على سبيل المثال، باستخدام -z -، سيكون اسم ملف النسخ الاحتياطي لـ src/patch/util.c هو src/patch/util.c-.

-Z أو --set-utc
عيّن أوقات التعديل والوصول للملفات التي تم تصحيحها من الطوابع الزمنية الموجودة في رؤوس التصحيح. ما لم يتم تحديدها في الطوابع الزمنية، افترض أن رؤوس التصحيح تستخدم التوقيت العالمي المنسق (UTC، والمعروف غالبًا باسم GMT). انظر أيضًا الخيار -T أو --set-time.

عادةً ما يمتنع الخياران -Z أو --set-utc و -T أو --set-time عن تعيين وقت الملف إذا لم يتطابق وقت الملف الأصلي مع الوقت الموجود في رأس التصحيح، أو إذا لم تتطابق محتوياته تمامًا مع التصحيح. ومع ذلك، إذا تم تقديم الخيار -f أو --force، فسيتم تعيين وقت الملف بغض النظر.

نظرًا لقيود تنسيق إخراج diff، لا يمكن لهذه الخيارات تحديث أوقات الملفات التي لم تتغير محتوياتها. أيضًا، إذا كنت تستخدم هذه الخيارات، فيجب عليك إزالة (على سبيل المثال، باستخدام make clean) جميع الملفات التي تعتمد على الملفات التي تم تطبيق التغييرات عليها، بحيث لا تسبب الاستدعاءات اللاحقة لـ make أي ارتباك بسبب أوقات الملفات التي تم تطبيق التغييرات عليها.

البيئة

PATCH_GET

يحدد ما إذا كان patch يحصل على الملفات المفقودة أو الملفات للقراءة فقط من أنظمة RCS أو ClearCase أو Perforce أو SCCS افتراضيًا؛ انظر الخيار -g أو --get.

POSIXLY_CORRECT

إذا تم تعيينه، فإن patch يلتزم بمعيار POSIX بشكل أكثر صرامة افتراضيًا؛ انظر الخيار --posix.

QUOTING_STYLE

القيمة الافتراضية للخيار --quoting-style.

SIMPLE_BACKUP_SUFFIX

اللاحقة المستخدمة لأسماء ملفات النسخ الاحتياطي البسيطة بدلاً من .orig.

TMPDIR، TMP، TEMP

الدليل الذي يتم فيه وضع الملفات المؤقتة؛ يستخدم patch أول متغير بيئة في هذه القائمة الذي تم تعيينه. إذا لم يتم تعيين أي منها، يكون الافتراضي يعتمد على النظام؛ وعادة ما يكون /tmp على أنظمة Unix.

VERSION_CONTROL أو PATCH_VERSION_CONTROL

يحدد نمط التحكم في الإصدار؛ انظر الخيار -v أو --version-control.

الملفات

$TMPDIR/p*
ملفات مؤقتة

/dev/tty
وحدة التحكم الطرفية؛ تُستخدم للحصول على إجابات للأسئلة التي يتم طرحها على المستخدم.

انظر أيضًا

diff(1)، ed(1)، merge(1).

مارشال ت. روز وإينار أ. ستيفيرود، معيار مقترح لتغليف الرسائل، (https://datatracker.ietf.org/doc/html/rfc934) RFC 934 (1985-01).

ملاحظات للمرسلين

هناك عدة أشياء يجب أن تضعها في الاعتبار إذا كنت سترسل تصحيحات.

قم بإنشاء التصحيح الخاص بك بشكل منهجي. عند استخدام نظام التحكم في الإصدار، يجب أن يكون هذا سهلاً؛ على سبيل المثال، مع Git، يمكنك استخدام git diff. خلاف ذلك، فإن إحدى الطرق الجيدة هي الأمر diff -Naur old new حيث يحدد old و new الأدلة القديمة والجديدة. يجب ألا تحتوي الأسماء old و new على أي شرطات مائلة.

إذا كان التصحيح يجب أن ينقل طوابع زمنية للملفات بالإضافة إلى محتويات الملفات، فيجب أن تحتوي رؤوس أوامر diff الخاصة به على تواريخ وأوقات بتنسيق Unix التقليدي في التوقيت العالمي، بحيث يمكن للمستلمين استخدام الخيار -Z أو --set-utc. فيما يلي مثال لأمر لإنشاء مثل هذه الرؤوس، باستخدام بناء جملة Bourne shell:

LC_ALL=C TZ=UTC0 diff -Naur myprog-2.7 myprog-2.8

أخبر المستلمين بكيفية تطبيق التصحيح عن طريق إخبارهم بالدليل الذي يجب عليهم الانتقال إليه، والخيار الذي يجب عليهم استخدامه. الخيار -Np1 موصى به. اختبر الإجراء الخاص بك عن طريق التظاهر بأنك مستلم وتطبيق التصحيح الخاص بك على نسخة من الملفات الأصلية.

يمكنك توفير الكثير من المتاعب للآخرين عن طريق الاحتفاظ بملف patchlevel.h يتم تصحيحه لزيادة مستوى التصحيح كأول اختلاف في ملف التصحيح الذي ترسله. إذا وضعت سطر Prereq: فيه، فلن يسمح لهم بتطبيق التصحيحات بترتيب غير صحيح دون أي تحذير.


يمكنك إنشاء ملف عن طريق إرسال اختلاف (diff) يقارن بين /dev/null أو ملف فارغ بتاريخ الحقبة (1970-01-01 00:00:00 UTC) بالملف الذي تريد إنشاؤه. هذا يعمل فقط إذا كان الملف الذي تريد إنشاؤه غير موجود بالفعل في الدليل المستهدف. على العكس من ذلك، يمكنك حذف ملف عن طريق إرسال اختلاف سياقي (context diff) يقارن الملف المراد حذفه بملف فارغ بتاريخ الحقبة. سيتم حذف الملف ما لم يكن الأمر patch متوافقًا مع معيار POSIX ولم يتم إعطاء الخيار -E أو --remove-empty-files. إحدى الطرق السهلة لإنشاء تصحيحات (patches) تقوم بإنشاء وحذف الملفات هي استخدام الخيار -N أو --new-file الخاص بـ GNU diff.

إذا كان من المفترض أن يستخدم المستلم الخيار -pN، فلا ترسل إخراجًا يبدو كهذا:

diff -Naur v2.0.29/prog/README prog/README
--- v2.0.29/prog/README   Mon Mar 10 15:13:12 2024
+++ prog/README   Mon Mar 17 14:58:22 2024

لأن اسمي الملفين يحتويان على أعداد مختلفة من الشرطات المائلة، وإصدارات مختلفة من الأمر patch تفسر أسماء الملفات بشكل مختلف. لتجنب الارتباك، أرسل إخراجًا يبدو كهذا بدلاً من ذلك:

diff -Naur v2.0.29/prog/README v2.0.30/prog/README
--- v2.0.29/prog/README   Mon Mar 10 15:13:12 2024
+++ v2.0.30/prog/README   Mon Mar 17 14:58:22 2024

تجنب إرسال التصحيحات التي تقارن بين أسماء ملفات النسخ الاحتياطي مثل README.orig، حيث قد يؤدي ذلك إلى تضليل الأمر patch وجعله يقوم بتطبيق التصحيح على ملف النسخ الاحتياطي بدلاً من الملف الفعلي. بدلًا من ذلك، أرسل التصحيحات التي تقارن بين نفس أسماء الملفات الأساسية في أدلة مختلفة، على سبيل المثال old/README و new/README.

احرص على عدم إرسال تصحيحات معكوسة، حيث يجعل ذلك المستخدمين يتساءلون عما إذا كانوا قد طبقوا التصحيح بالفعل.

حاول ألا تجعل التصحيح الخاص بك يعدل الملفات المشتقة (مثل الملف configure حيث يوجد سطر configure: configure.ac في ملف makefile)، حيث يجب أن يكون المستلم قادرًا على إعادة إنشاء الملفات المشتقة على أي حال. إذا كان يجب عليك إرسال اختلافات في الملفات المشتقة، فقم بإنشاء الاختلافات باستخدام التوقيت العالمي المنسق (UTC)، واجعل المستلمين يطبقون التصحيح باستخدام الخيار -Z أو --set-utc، واجعلهم يزيلون أي ملفات غير مصححة تعتمد على الملفات التي تم تصحيحها (على سبيل المثال، باستخدام make clean).

في حين أنك قد تتمكن من وضع 582 قائمة اختلاف في ملف واحد، فقد يكون من الأفضل تجميع التصحيحات ذات الصلة في ملفات منفصلة في حالة حدوث خطأ ما.

تشخيص المشاكل

تشير التشخيصات عمومًا إلى أن الأمر patch لم يتمكن من تحليل ملف التصحيح الخاص بك.

إذا تم إعطاء الخيار --verbose، فإن الرسالة "Hmm..." تشير إلى أن هناك نصًا غير معالج في ملف التصحيح وأن الأمر patch يحاول تخمين ما إذا كان هناك تصحيح في هذا النص، وإذا كان الأمر كذلك، فما نوع التصحيح.

يكون رمز الخروج الخاص بالأمر patch هو 0 إذا تم تطبيق جميع الأجزاء بنجاح، و 1 إذا لم يتمكن بعض الأجزاء من التطبيق أو كانت هناك تعارضات في الدمج، و 2 إذا كانت هناك مشاكل أكثر خطورة. عند تطبيق مجموعة من التصحيحات في حلقة، من الجيد أن تتحقق من رمز الخروج هذا حتى لا تقوم بتطبيق تصحيح لاحق على ملف تم تصحيحه جزئيًا.

تحذيرات

لا يمكن للاختلافات السياقية (context diffs) تمثيل إنشاء أو حذف ملفات فارغة، أو أدلة فارغة، أو ملفات خاصة مثل الروابط الرمزية بشكل موثوق. كما لا يمكنها تمثيل تغييرات في بيانات تعريف الملفات مثل الملكية أو الأذونات أو ما إذا كان ملف واحد عبارة عن رابط ثابت لملف آخر. إذا كانت هناك حاجة إلى تغييرات كهذه أيضًا، فيجب أن يصاحب التصحيح تعليمات منفصلة (على سبيل المثال، برنامج نصي shell) لإنجازها.


لا يمكن لـ `patch` تحديد ما إذا كانت أرقام الأسطر غير صحيحة في ملف `ed script`، ويمكنه فقط اكتشاف أرقام الأسطر غير الصحيحة في `diff` عادي عندما يجد تغييرًا أو حذفًا. قد يعاني `context diff` الذي يستخدم عامل تشتت 3 من نفس المشكلة. يجب عليك على الأرجح استخدام `context diff` في هذه الحالات لمعرفة ما إذا كانت التغييرات منطقية. بالطبع، يعد التجميع بدون أخطاء مؤشرًا جيدًا على أن التصحيح قد نجح، ولكنه ليس مضمونًا دائمًا.

عادةً ما ينتج `patch` النتائج الصحيحة، حتى عندما يتعين عليه القيام بالكثير من التخمينات. ومع ذلك، لا تضمن النتائج إلا عند تطبيق التصحيح على نفس إصدار الملف الذي تم إنشاء التصحيح منه.

مشكلات التوافق

يحدد معيار POSIX سلوكًا يختلف عن GNU patch.

في POSIX patch، عندما لا يتم استخدام -b، لا يتم إنشاء نسخ احتياطية حتى في حالة وجود عدم تطابق. في GNU patch، يتم تمكين هذا السلوك باستخدام الخيار --no-backup-if-mismatch، أو عن طريق الامتثال لمعيار POSIX باستخدام الخيار --posix أو عن طريق تعيين متغير البيئة POSIXLY_CORRECT.

عند تخمين اسم الملف المراد تصحيحه من رأس التصحيح، يستخدم patch طريقة معقدة وهي اختيارية ومتوافقة مع معيار POSIX. تكون الطريقة مكافئة لمعيار POSIX إذا كانت أسماء الملفات في رأس context diff وسطر Index متطابقة بعد إزالة البادئات. يكون التصحيح الخاص بك متوافقًا بشكل طبيعي إذا كانت أسماء الملفات في كل رأس تحتوي على نفس عدد الشرطات المائلة.

اقتصر على الخيارات التالية عند إرسال تعليمات تهدف إلى تنفيذها بواسطة أي شخص يستخدم GNU patch أو تصحيحًا يتوافق مع معيار POSIX. المسافات اختيارية في القائمة التالية.

-b
-c
-d dir
-D define
-e
-i patchfile
-l
-n
-N
-o outfile
-p num
-R
-r rejectfile
-u

الأخطاء

يرجى الإبلاغ عن الأخطاء عبر البريد الإلكتروني إلى <_>.

إذا تم تكرار التعليمات البرمجية (على سبيل المثال باستخدام #ifdef OLDCODE ... #else ... #endif)، فإن patch غير قادر على تصحيح كلا الإصدارين، وإذا نجح في ذلك، فمن المحتمل أن يقوم بتصحيح الإصدار الخاطئ، ويخبرك بأنه نجح أيضًا.

إذا قمت بتطبيق تصحيح قمت بتطبيقه بالفعل، فإن patch يعتقد أنه تصحيح معكوس، ويعرض إلغاء تطبيق التصحيح. يمكن اعتبار هذا بمثابة ميزة.

إن حساب كيفية دمج جزء من التعليمات البرمجية أصعب بكثير من استخدام الخوارزمية الغامضة القياسية. تؤدي الأجزاء الأكبر، والمزيد من السياق، والانحراف الأكبر عن الموقع الأصلي، والتطابق الأسوأ إلى إبطاء الخوارزمية.

حقوق النشر

حقوق النشر © 1989-2025 مؤسسة البرمجيات الحرة. حقوق النشر © 1984-1986، 1988 لاري وول.

يُمنح الإذن لإنشاء وتوزيع نسخ طبق الأصل من هذا الدليل شريطة الحفاظ على إشعار حقوق النشر وإشعار الإذن هذا على جميع النسخ.


يُسمح بنسخ وتوزيع نسخ معدلة من هذا الدليل وفقًا للشروط الخاصة بالنسخ الحرفي، شريطة أن يتم توزيع العمل المشتق الناتج بأكمله بموجب شروط إشعار إذن مماثل لهذا.

يُسمح بنسخ وتوزيع ترجمات لهذا الدليل إلى لغة أخرى، وفقًا للشروط المذكورة أعلاه للنسخ المعدلة، باستثناء أنه يمكن تضمين إشعار الإذن هذا في الترجمات المعتمدة من أصحاب حقوق الطبع والنشر بدلاً من تضمينه في النسخة الإنجليزية الأصلية.

المؤلفون

كتب لاري وول النسخة الأصلية من برنامج patch. قام بول إجرت بإزالة الحدود التعسفية لبرنامج patch؛ وأضاف دعمًا للملفات الثنائية، وتعيين أوقات الملفات، وحذف الملفات؛ وجعله متوافقًا بشكل أفضل مع معيار POSIX. تشمل المساهمات الأخرى واين ديفيسون، الذي أضاف دعم unidiff، وديفيد ماكنزي، الذي أضاف دعم التكوين والنسخ الاحتياطي. أضاف أندرياس غرونباخ دعمًا للدمج.