'\" t .TH "CARGO\-YANK" "1" .nh .ad l .ss \n[.ss] 0 .SH "نام (NAME)" cargo\-yank \- حذف یک کریت ارسال‌شده از نمایه .SH "خلاصه دستور (SYNOPSIS)" \fBcargo yank\fR [\fIoptions\fR] \fIcrate\fR@\fIversion\fR .br \fBcargo yank\fR [\fIoptions\fR] \fB\-\-version\fR \fIversion\fR [\fIcrate\fR] .SH "توضیحات (DESCRIPTION)" دستور yank نسخهٔ یک کریت که قبلاً منتشر شده است را از نمایهٔ (index) کارساز حذف می‌کند. این دستور هیچ داده‌ای را پاک نمی‌کند و کریت همچنان از طریق پیوند بارگیری مخزن (registry) برای دانلود در دسترس خواهد بود. .sp ابزار Cargo از نسخهٔ yank‌شده برای هیچ پروژهٔ جدید یا دریافت کدی (checkout) بدون فایل قفل (lockfile) از پیش موجود استفاده نخواهد کرد، و اگر دیگر هیچ نسخهٔ سازگاری برای کریت شما وجود نداشته باشد، یک خطا تولید می‌کند. .sp این دستور مستلزم آن است که هویت شما با گزینهٔ \fB\-\-token\fR یا با استفاده از \fBcargo\-login\fR(1) احراز شده باشد. .sp اگر نام کریت مشخص نشود، از نام بسته در دایرکتوری جاری استفاده خواهد شد. .SS "نحوه کارکرد yank" به عنوان مثال، کریت \fBfoo\fR نسخهٔ \fB1.5.0\fR را منتشر کرده و کریت دیگری به نام \fBbar\fR وابستگی خود را به نسخهٔ \fBfoo = "1.5"\fR اعلام کرده است. اکنون \fBfoo\fR نسخهٔ جدید \fB2.0.0\fR را که از نظر semver سازگار نیست منتشر می‌کند، و متوجه یک مشکل بحرانی در \fB1.5.0\fR می‌شود. اگر \fB1.5.0\fR اصطلاحاً yank شود، هیچ پروژهٔ جدید یا checkout بدون lockfile موجود قادر به استفاده از کریت \fBbar\fR نخواهد بود زیرا به \fB1.5\fR متکی است. .sp در این حالت، نگهدارندگان \fBfoo\fR باید پیش از yank کردن \fB1.5.0\fR، ابتدا یک نسخهٔ سازگار با semver مانند \fB1.5.1\fR را منتشر کنند تا \fBbar\fR و تمام پروژه‌های وابسته به آن همچنان به کار خود ادامه دهند. .sp به عنوان مثالی دیگر، کریت \fBbar\fR را با نسخه‌های منتشرشدهٔ \fB1.5.0\fR، \fB1.5.1\fR، \fB1.5.2\fR، \fB2.0.0\fR و \fB3.0.0\fR در نظر بگیرید. جدول زیر نسخه‌هایی را که cargo می‌تواند در صورت نبود lockfile پس از yank شدن یک نسخهٔ مشخص، برای نیازمندی‌های مختلف SemVer استفاده کند، مشخص می‌کند: .TS allbox tab(:); lt lt lt lt. T{ نسخهٔ yank‌شده / نیازمندی SemVer T}:T{ \fBbar = "1.5.0"\fR T}:T{ \fBbar = "=1.5.0"\fR T}:T{ \fBbar = "2.0.0"\fR T} T{ \fB1.5.0\fR T}:T{ استفاده از \fB1.5.1\fR یا \fB1.5.2\fR T}:T{ \fBبازگرداندن خطا\fR T}:T{ استفاده از \fB2.0.0\fR T} T{ \fB1.5.1\fR T}:T{ استفاده از \fB1.5.0\fR یا \fB1.5.2\fR T}:T{ استفاده از \fB1.5.0\fR T}:T{ استفاده از \fB2.0.0\fR T} T{ \fB2.0.0\fR T}:T{ استفاده از \fB1.5.0\fR، \fB1.5.1\fR یا \fB1.5.2\fR T}:T{ استفاده از \fB1.5.0\fR T}:T{ \fBبازگرداندن خطا\fR T} .TE .sp .SS "چه زمانی باید yank کرد" کریت‌ها تنها باید در شرایط استثنایی yank شوند؛ به عنوان مثال، انتشار تصادفی، ناسازگاری ناخواستهٔ SemVer، یا معیوب بودن اساسی و غیرقابل استفاده بودن یک کریت. در صورت وجود آسیب‌پذیری‌های امنیتی، \fIRustSec\fR معمولاً سازوکاری با اختلال کمتر برای آگاه‌سازی کاربران و تشویق آن‌ها به ارتقا است، و از احتمال ایجاد اختلال عمده در پروژه‌های پایین‌دستی صرف‌نظر از میزان تأثیرپذیری آن‌ها از آسیب‌پذیری مربوطه جلوگیری می‌کند. .sp یک جریان کاری معمول این است که پس از انتشار یک نسخهٔ سازگار با semver، کریت yank شود تا احتمال جلوگیری از کامپایل کریت‌های وابسته کاهش یابد. .sp هنگام رسیدگی به مسائل مربوط به حق نشر (کپی‌رایت)، مجوزها، یا داده‌های شخصی در یک کریت منتشرشده، صرفاً yank کردن آن ممکن است کافی نباشد. در چنین مواردی، با نگه‌دارندگان مخزنی که استفاده کرده‌اید تماس بگیرید. برای crates.io، به \fIخط‌مشی‌های آن‌ها\fR مراجعه کرده و از طریق با آن‌ها ارتباط برقرار کنید. .sp اگر اطلاعات احراز هویت (credentials) افشا شده باشد، اقدام توصیه‌شده ابطال فوری آن‌ها است. هنگامی که یک کریت منتشر شد، تعیین اینکه آیا اطلاعات احراز هویت افشاشده کپی شده‌اند یا خیر غیرممکن است. عمل yank فقط مانع از آن می‌شود که Cargo به‌طور پیش‌فرض این نسخه را هنگام حل وابستگی‌ها انتخاب کند. فایل‌های lock موجود یا دانلودهای مستقیم تحت تأثیر قرار نمی‌گیرند، بنابراین yank کردن نمی‌تواند جلوی انتشار بیشتر اطلاعات احراز هویت افشاشده را بگیرد. .SH "گزینه‌ها (OPTIONS)" .SS "گزینه‌های Yank" .sp \fB\-\-vers\fR \fIversion\fR, \fB\-\-version\fR \fIversion\fR .RS 4 نسخه‌ای که باید yank شود یا از حالت yank خارج شود (un\-yank). .RE .sp \fB\-\-undo\fR .RS 4 لغو عملیات yank، و بازگرداندن نسخه به نمایه (index). .RE .sp \fB\-\-token\fR \fItoken\fR .RS 4 توکن API مورد استفاده برای احراز هویت. این گزینه بر توکن ذخیره‌شده در فایل اطلاعات احراز هویت (که توسط \fBcargo\-login\fR(1) ایجاد می‌شود) اولویت دارد. .sp متغیرهای محیطی \fIپیکربندی Cargo\fR می‌توانند برای جایگزینی توکن‌های ذخیره‌شده در فایل اعتبارسنجی استفاده شوند. توکن برای crates.io را می‌توان با متغیر محیطی \fBCARGO_REGISTRY_TOKEN\fR تعیین کرد. توکن‌های سایر مخازن را می‌توان با متغیرهای محیطی به قالب \fBCARGO_REGISTRIES_NAME_TOKEN\fR مشخص نمود که در آن \fBNAME\fR نام مخزن با تمام حروف بزرگ است. .RE .sp \fB\-\-index\fR \fIindex\fR .RS 4 آدرس اینترنتی (URL) نمایهٔ مخزن مورد استفاده. .RE .sp \fB\-\-registry\fR \fIregistry\fR .RS 4 نام مخزن مورد استفاده. نام‌های مخازن در \fIفایل‌های پیکربندی Cargo\fR تعریف می‌شوند. اگر مشخص نشود، مخزن پیش‌فرض استفاده خواهد شد که توسط کلید پیکربندی \fBregistry.default\fR تعیین می‌شود و مقدار پیش‌فرض آن \fBcrates\-io\fR است. .RE .SS "گزینه‌های نمایش" .sp \fB\-v\fR, \fB\-\-verbose\fR .RS 4 استفاده از خروجی پرجزئیات. می‌تواند دو بار برای خروجی \[lq]بسیار پرجزئیات\[rq] مشخص شود که شامل خروجی‌های اضافی مانند هشدارهای وابستگی و خروجی اسکریپت ساخت است. همچنین می‌تواند با \fIمقدار پیکربندی\fR به نام \fBterm.verbose\fR تعیین شود. .RE .sp \fB\-q\fR, \fB\-\-quiet\fR .RS 4 عدم چاپ پیام‌های گزارش cargo. همچنین می‌تواند با \fIمقدار پیکربندی\fR به نام \fBterm.quiet\fR تعیین شود. .RE .sp \fB\-\-color\fR \fIwhen\fR .RS 4 کنترل زمان استفاده از خروجی رنگی. مقادیر معتبر: .sp .RS 4 \h'-04'\(bu\h'+03'\fBauto\fR (پیش‌فرض): تشخیص خودکار اینکه آیا پشتیبانی از رنگ در پایانه موجود است یا خیر. .RE .sp .RS 4 \h'-04'\(bu\h'+03'\fBalways\fR: همیشه رنگ‌ها را نمایش بده. .RE .sp .RS 4 \h'-04'\(bu\h'+03'\fBnever\fR: هرگز رنگ‌ها را نمایش نده. .RE .sp همچنین می‌تواند با \fIمقدار پیکربندی\fR به نام \fBterm.color\fR تعیین شود. .RE .SS "گزینه‌های عمومی" .sp \fB+\fR\fItoolchain\fR .RS 4 اگر Cargo با rustup نصب شده باشد و اولین آرگومان \fBcargo\fR با \fB+\fR شروع شود، به عنوان نام زنجیره ابزار (toolchain) در rustup تفسیر می‌شود (مانند \fB+stable\fR یا \fB+nightly\fR). برای اطلاعات بیشتر در مورد نحوهٔ عملکرد بازنویسی‌های زنجیره ابزار، به \fIمستندات rustup\fR مراجعه کنید. .RE .sp \fB\-\-config\fR \fIKEY=VALUE\fR یا \fIPATH\fR .RS 4 یک مقدار پیکربندی Cargo را بازنویسی می‌کند. این آرگومان باید در ساختار TOML به صورت \fBKEY=VALUE\fR باشد، یا به عنوان یک مسیر به یک فایل پیکربندی اضافی ارائه شود. این پرچم می‌تواند چندین بار مشخص شود. برای اطلاعات بیشتر به \fIبخش بازنویسی‌های خط فرمان\fR مراجعه کنید. .RE .sp \fB\-C\fR \fIPATH\fR .RS 4 دایرکتوری کاری فعلی را قبل از اجرای هرگونه عملیات مشخص‌شده تغییر می‌دهد. این امر مواردی از جمله مکانی را که cargo به‌طور پیش‌فرض به دنبال مانیفست پروژه (\fBCargo.toml\fR) می‌گردد، و همچنین دایرکتوری‌های جستجو شده برای کشف \fB\&.cargo/config.toml\fR را تحت تأثیر قرار می‌دهد. این گزینه باید قبل از نام دستور بیاید، به عنوان مثال \fBcargo \-C path/to/my\-project build\fR\&. .sp این گزینه فقط در \fIکانال nightly\fR در دسترس است و برای فعال‌سازی به پرچم \fB\-Z unstable\-options\fR نیاز دارد (به \fI#10098\fR مراجعه کنید). .RE .sp \fB\-h\fR, \fB\-\-help\fR .RS 4 اطلاعات راهنما را چاپ می‌کند. .RE .sp \fB\-Z\fR \fIflag\fR .RS 4 پرچم‌های ناپایدار (فقط nightly) برای Cargo. برای جزئیات، دستور \fBcargo \-Z help\fR را اجرا کنید. .RE .SH "محیط (ENVIRONMENT)" برای جزئیات بیشتر دربارهٔ متغیرهای محیطی که Cargo می‌خواند، به \fIمرجع\fR مراجعه کنید. .SH "وضعیت خروج (EXIT STATUS)" .sp .RS 4 \h'-04'\(bu\h'+03'\fB0\fR: با موفقیت به پایان رسید. .RE .sp .RS 4 \h'-04'\(bu\h'+03'\fB101\fR: اجرای Cargo با شکست مواجه شد. .RE .SH "مثال‌ها (EXAMPLES)" .sp .RS 4 \h'-04' 1.\h'+01'حذف یک کریت از نمایه (yank): .sp .RS 4 .nf cargo yank foo@1.0.7 .fi .RE .RE .SH "همچنین ببینید (SEE ALSO)" \fBcargo\fR(1), \fBcargo\-login\fR(1), \fBcargo\-publish\fR(1)