UNZIPSFX(1L) UNZIPSFX(1L)

unzipsfx - استاب خوداستخراج‌کننده برای الحاق به ابتدای بایگانی‌های ZIP

<نام ترکیب unzipsfx+archive> [-cfptuz[ajnoqsCLV$]] [file(s) ... [-x xfile(s) ...]]

برنامهٔ unzipsfx نسخه‌ای تغییریافته از unzip(1L) است که برای الحاق به ابتدای بایگانی‌های موجود ZIP طراحی شده تا بایگانی‌های خوداستخراج‌کننده (self-extracting) بسازد. به جای اینکه نخستین آرگومان غیرگزینه‌ای خود را به عنوان فایل(های) zip برای استخراج در نظر بگیرد، unzipsfx خود را تحت نامی که با آن فراخوانی شده جستجو می‌کند و محتویات بایگانی ضمیمه‌شده را بررسی یا استخراج می‌نماید. از آنجا که استاب اجرایی (executable stub) حجم بایگانی را افزایش می‌دهد (درحالی‌که تمام هدف آن کوچک ماندن تا حد ممکن است)، تعدادی از قابلیت‌های کم‌اهمیت‌تر unzip معمولی حذف شده‌اند. از جملهٔ این موارد می‌توان به صفحهٔ راهنما، توابع فهرست‌گیری و عیب‌یابی (-l و -v)، و توانایی باز کردن قالب‌های فشرده‌سازی قدیمی‌تر (روش‌های «reduce»، «shrink» و «implode») اشاره کرد. قابلیت استخراج در دایرکتوری‌ای غیر از دایرکتوری جاری می‌تواند به عنوان یک گزینه در زمان کامپایل انتخاب شود که از نسخهٔ ۵.۵ UnZipSFX به‌طور پیش‌فرض فعال است. به همین ترتیب، رمزگشایی نیز به عنوان یک گزینهٔ زمان کامپایل پشتیبانی می‌شود، اما باید از آن اجتناب کرد مگر اینکه بایگانی ضمیمه‌شده شامل فایل‌های رمزگذاری‌شده باشد. از نگارش ۵.۵ به بعد، گزینهٔ دیگری در زمان کامپایل ویژگی سادهٔ «اجرای دستور پس از استخراج» را اضافه می‌کند. این ویژگی در حال حاضر با قابلیت «استخراج در یک دایرکتوری متفاوت» ناسازگار بوده و به‌طور پیش‌فرض غیرفعال است.

توجه داشته باشید که بایگانی‌های خوداستخراج‌کنندهٔ ساخته‌شده با unzipsfx در بین سیستم‌عامل‌های مختلف دقیقاً به اندازهٔ خود فایل اجرایی unzip قابلیت حمل دارند (نه بیشتر و نه کمتر). به‌طور کلی، یک بایگانی خوداستخراج‌کننده که برای مثال روی یک سیستم یونیکس خاص ساخته شده است، تنها تحت همان توزیع یونیکس به‌صورت خودکار استخراج می‌شود. با این حال، هنوز می‌توان از unzip معمولی برای استخراج بایگانی تعبیه‌شده همانند هر فایل zip عادی دیگری استفاده کرد، اگرچه هشداری بی‌خطر دربارهٔ بایت‌های اضافی در ابتدای فایل zip صادر خواهد شد. با وجود این، بایگانی خوداستخراج‌کننده از نظر فنی یک بایگانی معتبر ZIP نیست، و ممکن است PKUNZIP قادر به آزمایش یا استخراج آن نباشد. این محدودیت به دلیل روش ساده‌ای است که بایگانی با آن ایجاد می‌شود؛ ساختار دایرکتوری داخلی به‌روزرسانی نمی‌شود تا بایت‌های اضافی الحاق‌شده به ابتدای فایل zip اصلی را منعکس کند.

[file(s)]
فهرستی اختیاری از اعضای بایگانی که باید پردازش شوند. عبارات باقاعده (کاراکترهای جانشین یا wildcards) مشابه آنچه در egrep(1) یونیکس وجود دارد، می‌توانند برای مطابقت با چندین عضو استفاده شوند. این کاراکترهای جانشین می‌توانند شامل موارد زیر باشند:
*
با دنباله‌ای از ۰ یا چند کاراکتر مطابقت دارد.
?
دقیقاً با ۱ کاراکتر مطابقت دارد.
[...]
با هر تک‌کاراکتری که درون براکت‌ها یافت شود مطابقت دارد؛ محدوده‌ها با یک کاراکتر آغازین، یک خط تیره، و یک کاراکتر پایانی مشخص می‌شوند. اگر بلافاصله پس از براکت چپ، یک علامت تعجب یا علامت توان ('!' یا '^') بیاید، دامنهٔ کاراکترهای درون براکت متمم می‌شود (یعنی هر چیزی به‌جز کاراکترهای داخل براکت‌ها به عنوان مورد منطبق در نظر گرفته می‌شود).
(حتماً هر کاراکتری را که ممکن است توسط سیستم‌عامل تفسیر یا تغییر داده شود، به‌ویژه در یونیکس و VMS، در علامت نقل‌قول قرار دهید.)
[-x xfile(s)]
فهرستی اختیاری از اعضای بایگانی که باید از پردازش مستثنی شوند. از آنجا که کاراکترهای جانشین با جداکننده‌های دایرکتوری ('/') مطابقت دارند، این گزینه می‌تواند برای مستثنی کردن فایل‌هایی که در زیردایرکتوری‌ها قرار دارند استفاده شود. برای مثال، دستور «foosfx *.[ch] -x */*» تمام فایل‌های منبع C را در دایرکتوری اصلی استخراج می‌کند، اما هیچ فایلی را از زیردایرکتوری‌ها استخراج نخواهد کرد. بدون گزینهٔ -x، تمام فایل‌های منبع C در تمام دایرکتوری‌های درون فایل zip استخراج خواهند شد.

اگر unzipsfx با تعریف مقدار SFX_EXDIR کامپایل شده باشد، گزینهٔ زیر نیز فعال خواهد بود:

[-d exdir]
دایرکتوری اختیاری برای استخراج فایل‌ها. به‌طور پیش‌فرض، همهٔ فایل‌ها و زیردایرکتوری‌ها در دایرکتوری جاری بازسازی می‌شوند؛ گزینهٔ -d اجازهٔ استخراج در یک دایرکتوری دلخواه را می‌دهد (البته با فرض اینکه کاربر مجوز نوشتن در آن دایرکتوری را داشته باشد). این گزینه و دایرکتوری می‌توانند بدون فاصلهٔ خالی (whitespace) به یکدیگر متصل شوند، اما توجه داشته باشید که این کار ممکن است رفتار معمول پوسته (shell) را مختل کند. به‌ویژه، عبارت «-d ~» (تیلدا) توسط پوسته‌های C در یونیکس به نام دایرکتوری خانگی کاربر بسط می‌یابد، در حالی که «-d~» به عنوان یک زیردایرکتوری به نام تحت‌اللفظی «~» در دایرکتوری جاری در نظر گرفته می‌شود. unzipsfx از گزینه‌های زیر در unzip(1L) پشتیبانی می‌کند: -c و -p (استخراج به خروجی استاندارد/صفحه‌نمایش)، -f و -u (تازه‌سازی و به‌روزرسانی فایل‌های موجود هنگام استخراج)، -t (آزمایش آرشیو) و -z (چاپ توضیح آرشیو). تمام گزینه‌های معمول فهرست‌کردن (-l، -v و -Z) حذف شده‌اند، اما گزینهٔ آزمایش (-t) می‌تواند به عنوان یک فهرست‌کردن ساده و حداقلی استفاده شود. همچنین، کسانی که آرشیوهای خود‌بازشونده ایجاد می‌کنند ممکن است مایل باشند فهرست کوتاهی را در بخش توضیح zipfile قرار دهند.

برای توضیحات کامل‌تر درباره این گزینه‌ها، unzip(1L) را ببینید.

در حال حاضر unzipsfx از تمام اصلاح‌کننده‌های unzip(1L) پشتیبانی می‌کند: -a (تبدیل فایل‌های متنی)، -n (عدم بازنویسی تحت هر شرایطی)، -o (بازنویسی بدون پرسش)، -q (عملیات در حالت بی‌صدا)، -C (تطبیق نام‌ها بدون حساسیت به حروف بزرگ و کوچک)، -L (تبدیل نام‌های حروف بزرگ سیستم‌عامل به حروف کوچک)، -j (نادیده‌گرفتن مسیرها) و -V (حفظ شماره نگارش‌ها)؛ به علاوه گزینه‌های مخصوص سیستم‌عامل زیر: -X (بازیابی اطلاعات مالکیت/حفاظت VMS)، -s (تبدیل فاصله‌ها در نام فایل‌ها به زیرخط [DOS، OS/2، NT]) و -$ (بازیابی برچسب حجم دیسک [DOS، OS/2، NT، Amiga]).

(پشتیبانی از تبدیل متن عادی ASCII ممکن است در نگارش‌های آینده حذف شود، زیرا برای سازندهٔ آرشیو به اندازه کافی ساده است که اطمینان حاصل کند فایل‌های متنی قالب مناسب برای سیستم‌عامل محلی را دارند. تبدیل EBCDIC البته همچنان پشتیبانی خواهد شد، زیرا قالب zipfile مستلزم ذخیره‌سازی متن‌ها به صورت ASCII است.)

برای توضیحات کامل‌تر درباره این اصلاح‌کننده‌ها، unzip(1L) را ببینید.

برنامهٔ unzipsfx از همان متغیرهای محیطی استفاده می‌کند که unzip(1L) استفاده می‌کند، هرچند این موضوع احتمالاً تنها برای شخصی که در حال ساخت و آزمایش آرشیو خود‌بازشونده است اهمیت خواهد داشت. برای جزئیات، unzip(1L) را ببینید.

رمزگشایی دقیقاً مانند unzip(1L) پشتیبانی می‌شود؛ یعنی به‌صورت تعاملی با اعلان بدون بازتاب کاراکتر برای گذرواژه(ها). برای جزئیات، unzip(1L) را ببینید. بار دیگر توجه داشته باشید در صورتی که آرشیو هیچ فایل رمزگذاری‌شده‌ای ندارد، دلیلی برای استفاده از نگارشی از unzipsfx با پشتیبانی از رمزگشایی وجود ندارد؛ این کار فقط اندازه آرشیو را افزایش می‌دهد.

هنگامی که unzipsfx با تعریف CHEAP_SFX_AUTORUN کامپایل شده باشد، یک قابلیت سادهٔ «اجرای خودکار دستور» پشتیبانی می‌شود. می‌توانید با استفاده از ساختار زیر، دستوری را در بخش توضیح آرشیو Zip وارد کنید:

$AUTORUN$>[command line string]

هنگامی که unzipsfx نشانهٔ «$AUTORUN$>» را در ابتدای توضیح آرشیو Zip تشخیص دهد، باقی‌ماندهٔ سطر اول توضیح (تا نخستین نویسهٔ خط جدید) به عنوان یک دستور شل با استفاده از تابع «system» در کتابخانه اجرایی C به سیستم‌عامل فرستاده می‌شود. پیش از اجرای دستور، unzipsfx دستور را در کنسول نمایش داده و برای تأیید از کاربر سؤال می‌پرسد. هنگامی که کاربر با مشخص‌کردن گزینهٔ -q اعلان‌ها را غیرفعال کرده باشد، دستورهای اجرای خودکار هرگز اجرا نمی‌شوند.

در صورتی که توضیح آرشیو شامل سطرهای متنی بیشتری باشد، باقی‌ماندهٔ توضیح آرشیو پس از سطر اول به‌طور عادی نمایش داده می‌شود، مگر اینکه با مشخص‌کردن گزینهٔ -q عملیات بی‌صدا درخواست شده باشد.

برای ایجاد یک آرشیو خود‌بازشوندهٔ letters از یک zipfile معمولی letters.zip و تغییر دسترسی‌های آرشیو جدید به قابل اجرا برای همگان در Unix:

cat unzipsfx letters.zip > letters
chmod 755 letters
zip -A letters

برای ایجاد همان آرشیو در MS-DOS، OS/2 یا NT (به استفاده از گزینهٔ /b [دودویی/باینری] برای دستور copy توجه کنید):

copy /b unzipsfx.exe+letters.zip letters.exe
zip -A letters.exe

در VMS:

copy unzipsfx.exe,letters.zip letters.exe
letters == "$currentdisk:[currentdir]letters.exe"
zip -A letters.exe

(دستور append در VMS نیز ممکن است استفاده شود. دستور دوم برنامه جدید را به‌عنوان یک «دستور خارجی» قادر به دریافت آرگومان‌ها نصب می‌کند. خط سوم فرض می‌کند که Zip از پیش به‌صورت یک دستور خارجی نصب شده است.) در AmigaDOS:

MakeSFX letters letters.zip UnZipSFX

(برنامه MakeSFX در توزیع مبدأ UnZip و توزیع‌های باینری Amiga گنجانده شده است. «zip -A» روی آرشیوهای خود‌بازشونده در Amiga کار نمی‌کند.) برای آزمایش (یا فهرست‌کردن) آرشیو خود‌بازشوندهٔ تازه ایجادشده:

letters -t

برای آزمایش letters در حالت بی‌صدا، به طوری که فقط یک پیام خلاصه مبنی بر سالم بودن یا نبودن آرشیو چاپ شود:

letters -tqq

برای استخراج تمام محتویات در دایرکتوری جاری و بازسازی مجدد تمام فایل‌ها و زیردایرکتوری‌ها بر حسب نیاز:

letters

برای استخراج تمام فایل‌های *.txt (در Unix نماد «*» را درون کوتیشن بگذارید):

letters *.txt

برای استخراج همه‌چیز به‌جز فایل‌های *.txt:

letters -x *.txt

برای استخراج تنها فایل README به خروجی استاندارد (صفحه‌نمایش):

letters -c README

برای چاپ تنها توضیحِ zipfile:

letters -z
محدودیت اصلی و بنیادین unzipsfx این است که میان معماری‌ها یا سیستم‌عامل‌های مختلف قابل حمل نیست، و بنابراین آرشیوهای حاصل نیز چنین قابلیتی ندارند. با این حال، برای برخی معماری‌ها قابلیت حمل محدودی وجود دارد (به‌عنوان مثال، میان برخی از توزیع‌های یونیکس مبتنی بر Intel).

مشکل دیگر در پیاده‌سازی فعلی این است که از نظر فنی، هر آرشیوی که داده‌های زائد (junk) به ابتدای آن اضافه شده باشد، دیگر یک فایل zip معتبر محسوب نمی‌شود (مگر اینکه همان‌طور که در بالا اشاره شد، از zip(1) برای تنظیم مناسب آفست‌های فایل zip استفاده شود). ابزار unzip(1) این بایت‌های اضافه‌شده در ابتدا را شناسایی کرده و آن‌ها را نادیده می‌گیرد، زیرا برخی از پروتکل‌های انتقال فایل، به‌ویژه MacBinary، نیز به افزودن داده‌های زائد به ابتدا شناخته شده‌اند. اما ممکن است مجموعه ابزارهای فشرده‌سازی PKWARE قادر به مدیریت آرشیو دستکاری‌شده نباشند، مگر اینکه آفست‌های آن تنظیم شده باشند.

ابزار unzipsfx از متغیر PATH کاربر اطلاعی ندارد، بنابراین به‌طور کلی هنگام فراخوانی، آرشیو باید در دایرکتوری جاری باشد، یا اینکه یک مسیر کامل یا نسبی ارائه شود. اگر کاربر تلاش کند آرشیو را از دایرکتوری دیگری در PATH به‌جز دایرکتوری جاری استخراج کند، unzipsfx هشداری با مضمون «can't find myself» نمایش می‌دهد. این موضوع در Unix همیشه صادق است و در MS-DOS نیز بسته به کامپایلر مورد استفاده ممکن است در برخی موارد رخ دهد (Microsoft C نام برنامه را به‌طور کامل با مسیر مشخص می‌کند، اما کامپایلرهای دیگر ممکن است این کار را نکنند). در OS/2 و NT فراخوان‌های سیستمی موجود است که نام کامل مسیر را ارائه می‌دهند، بنابراین آرشیو را می‌توان از هر جایی در PATH کاربر فراخوانی کرد. وضعیت برای AmigaDOS، Atari TOS، MacOS و غیره مشخص نیست.

همان‌طور که در بالا اشاره شد، تعدادی از عملکردهای معمول unzip(1L) به منظور کوچک‌تر کردن unzipsfx حذف شده‌اند: اطلاعات مربوط به شیوه استفاده و عیب‌یابی، عملکردهای فهرست‌کردن و استخراج در دایرکتوری‌های دیگر. همچنین تنها فایل‌های ذخیره‌شده (stored) و فشرده‌شده با الگوریتم deflate پشتیبانی می‌شوند. با این حال، محدودیت اخیر عمدتاً به کسانی مربوط می‌شود که آرشیوهای SFX ایجاد می‌کنند.

کاربران VMS برای استفاده از هر یک از گزینه‌های unzipsfx، باید با نحوه پیکربندی آرشیوهای خود-استخراج‌شونده به‌صورت دستورهای خارجی (foreign commands) آشنا باشند. این کار برای یک استخراج ساده لازم نیست، اما دستور آن در این صورت به عنوان مثال به «run letters» تبدیل می‌شود (برای ادامه مثال‌های ارائه‌شده در بالا).

ابزار unzipsfx در Amiga برای ایجاد آرشیوهای خود-استخراج‌شونده کاربردی به استفاده از یک برنامه ویژه به نام MakeSFX نیاز دارد؛ اتصال و پیوست ساده فایل‌ها (concatenation) کارساز نیست. (برای کاربرانی با دیدگاه فنی، آرشیو ضمیمه‌شده به عنوان یک «debug hunk» تعریف می‌شود.) ممکن است مشکلات سازگاری میان سطوح ROM در Amigaهای قدیمی‌تر و مدل‌های جدیدتر وجود داشته باشد.

تمام باگ‌های فعلی موجود در unzip(1L) در unzipsfx نیز وجود دارند.

وضعیت خروج (سطح خطا یا error level) در unzipsfx دقیقاً همانند unzip(1L) است؛ به صفحه راهنمای مربوطه مراجعه کنید.

funzip(1L), unzip(1L), zip(1L), zipcloak(1L), zipgrep(1L), zipinfo(1L), zipnote(1L), zipsplit(1L)

صفحه خانگی Info-ZIP در حال حاضر در نشانی زیر قرار دارد:

http://www.info-zip.org/pub/infozip

یا

ftp://ftp.info-zip.org/pub/infozip .

گرگ رولوفس (Greg Roelofs) مسئول اعمال تغییرات اولیه لازم در UnZip برای ایجاد UnZipSFX بود. برای مشاهده فهرست کنونی نویسندگان Zip-Bugs به unzip(1L)، یا برای فهرست کامل مشارکت‌کنندگان Info-ZIP به فایل CONTRIBS در توزیع کد منبع UnZip مراجعه کنید.

20 April 2009 (v6.0) Info-ZIP