aent - آنلاین در ابر

برنامه:

نام

aegis new test - یک تست جدید به یک تغییر اضافه کنید

خلاصه

حمایت -تست_جدید [ انتخاب... ][ نام فایل...]
حمایت -تست_جدید -فهرست [ انتخاب...]
حمایت -تست_جدید -کمک

شرح

La حمایت -تست_جدید دستور برای افزودن یک تست جدید به یک تغییر استفاده می شود. یک فایل جدید ایجاد می شود
در دایرکتوری توسعه

آزمایش‌های جدید به‌طور پیش‌فرض روی «خودکار» هستند، مگر اینکه طور دیگری مشخص شده باشد.

پرونده نام تفسیر
برنامه aegis سعی می کند نام فایل پروژه را از نام فایل ها تعیین کند
در خط فرمان داده شده است. همه نام فایل ها در پروژه های aegis به عنوان نسبی ذخیره می شوند
به ریشه درخت دایرکتوری پایه. دایرکتوری توسعه و
دایرکتوری ادغام سایه هایی از این دایرکتوری پایه و بنابراین این نام های نسبی هستند
اینجا هم درخواست کن فایل های نام گذاری شده در خط فرمان ابتدا به مسیرهای مطلق تبدیل می شوند
در صورت لزوم سپس با مسیر پایه، دایرکتوری توسعه مقایسه می شوند
مسیر، و مسیر دایرکتوری ادغام، برای تعیین یک نام نسبی پایه. این است
اگر فایل نامگذاری شده خارج از یکی از این درختان دایرکتوری باشد، یک خطا رخ می دهد.

La -BAse_RElative ممکن است از گزینه برای ایجاد نام فایل های نسبی به عنوان تفسیر استفاده شود
نسبت به مسیر پایه؛ نام فایل های مطلق همچنان با انواع مختلف مقایسه خواهد شد
مسیرها به منظور تعیین نام نسبی پایه.

La relative_filename_preference در فایل پیکربندی کاربر ممکن است برای اصلاح استفاده شود
این رفتار پیش فرض دیدن aeuconf(5) برای اطلاعات بیشتر

تست نام فایل نسل
شما می توانید با مشخص کردن آن در خط فرمان، نام فایل خود را برای آزمایش انتخاب کنید.

اگر هیچ نام فایلی در خط فرمان مشخص نشده باشد، نام فایل آزمایشی به طور خودکار انتخاب می شود
تولید شده است. این توسط کنترل می شود new_test_filename زمینه پروژه
فایل پیکربندی (نگاه کنید به aepconf(5) برای اطلاعات بیشتر همه به طور خودکار تولید می شوند
نام فایل های آزمایشی در یک پروژه به صورت یکتا شماره گذاری می شوند. الگوی پیش فرض برای تست جدید
نام فایل ها "test/XX/tXXXX[am].sh"، جایی که XX 2 رقم اول شماره آزمون است،
XXXX عدد کل آزمون است و [صبح] برای تست های خودکار و m برای تست های دستی است.

اصلاح تست
آزمایش‌ها ممکن است در آینده با اضافه کردن آنها به یک تغییر با تغییر داده شوند aecp(1) فرمان.
آزمون‌ها نیز مانند هر فایل منبع دیگری مورد بررسی قرار می‌گیرند و مشمول فرآیند مشابهی هستند.

پرونده قالب
هنگامی که یک فایل جدید در دایرکتوری توسعه پروژه ایجاد می شود پیکربندی پرونده است
به دنبال الگویی برای فایل جدید شد. اگر یک الگو پیدا شد، فایل جدید خواهد بود
به الگو مقدار دهی اولیه می شود، در غیر این صورت خالی ایجاد می شود. دیدن aepconf(5) برای اطلاعات بیشتر
اطلاعات.

ساده ترین شکل استفاده از فایل های قالب است، مانند
file_template =
[
{
الگو = [ "*.c" ];
body = "${read_file ${قالب منبع/c abs}}";
},
{
pattern = [ "test/*/.sh" ];
body = "${read_file ${قالب منبع/تست abs}}";
},
];
همانطور که می بینید، فایل های قالب بخشی از منبع پروژه هستند، بنابراین می توانید آن را اضافه کنید
اعلامیه‌های حق چاپ و بسته‌بندی‌های مناسب، و غیره. منبع $ جایگزینی آنها را تعیین می کند،
اگر آنها بخشی از تغییر فعلی نباشند (و معمولاً نیستند).

فایل های قالب خود حاوی جایگزین هایی هستند. در $filename جایگزینی است
موجود است و حاوی نام فایل در حال ایجاد است. این را می توان در آن دستکاری کرد
روش های مختلف هنگام ساخت محتویات فایل مناسب. دیدن aesub(5) برای اطلاعات بیشتر
اطلاعات در مورد تعویض

همچنین امکان اجرای دستوری برای ایجاد فایل جدید وجود دارد. شما می توانید این کار را به جای انجام دهید
تعیین رشته بدنه، یعنی:
file_template =
[
{
الگو = [ "*" ];
body_command = "perl ${source template.pl abs} $filename";
},
];
دستور با دایرکتوری فعلی که در بالای دایرکتوری توسعه تنظیم شده است اجرا می شود.
اگر دستور نتواند فایل را ایجاد کند یک خطا است. می توانید این دو را با هم ترکیب کنید
تکنیک، بدن رشته و بدن_فرمان، اگر می خواهید

مراقب باشید که مطمئن شوید الگوی الگوی نام فایل آزمایشی با آن مطابقت دارد
new_test_filename رشته.

پرونده نام محدودیت ها
تعدادی کنترل برای محدود کردن شکل نام فایل های پروژه وجود دارد. همه از
این کنترل ها را ممکن است در فایل پیکربندی پروژه پیدا کنید، ببینید aepconf(5) برای اطلاعات بیشتر
اطلاعات مهمترین آنها در اینجا به اختصار توضیح داده شده است:

حداکثر_نام_فایل_طول = عدد صحیح;
این فیلد برای محدود کردن طول نام فایل ها استفاده می شود. همه فایل های جدید ممکن است نداشته باشند
اجزای مسیر طولانی تر از این اگر تنظیم نشده باشد، به طور پیش فرض روی 255 قرار می گیرد. برای حداکثر
قابل حمل بودن را باید روی 14 تنظیم کنید.

posix_filename_charset = boolean;
این فیلد ممکن است برای محدود کردن کاراکترهای مجاز در نام فایل‌ها به آن‌ها استفاده شود
به صراحت توسط POSIX مجاز است. پیش فرض به غلط اگر تنظیم نشده باشد، به این معنی است که شما هر چه دارید
سیستم عامل به جز فضای سفید و کاراکترهای با بیت بالا را تحمل می کند.
برای حداکثر قابلیت حمل باید این را تنظیم کنید درست.

dos_filename_required = boolean;
این فیلد ممکن است برای محدود کردن نام فایل ها به گونه ای استفاده شود که با DOS 8+3 مطابقت داشته باشند
محدودیت نام فایل و مجموعه کاراکتر نام فایل DOS. پیش فرض به غلط اگر نه
تنظیم شده است.

windows_filename_required = boolean;
این فیلد ممکن است برای محدود کردن نام فایل ها به گونه ای استفاده شود که با Windows98 مطابقت داشته باشند
و محدودیت های نام فایل WindowsNT و مجموعه کاراکترها. پیش فرض به غلط اگر تنظیم نشود

shell_safe_names = boolean;
این فیلد ممکن است برای محدود کردن نام فایل ها به گونه ای استفاده شود که حاوی پوسته نباشند
شخصیت های خاص پیش فرض به درست اگر تنظیم نشود اگر این فیلد روی غلط,
شما نیاز به استفاده از ${quote} جایگزینی در اطراف نام فایل در دستورات، به
اطمینان حاصل کنید که نام فایل های حاوی کاراکترهای خاص پوسته ناخواسته نباشد
اثرات جانبی. کاراکترهای عجیب و غریب در نام فایل ها نیز ممکن است وابستگی شما را گیج کنند
ابزار نگهداری

allow_white_space_in_filenames = boolean;
این فیلد ممکن است برای اجازه دادن به کاراکترهای فضای سفید در نام فایل استفاده شود. این اراده
اجازه دهید کاراکترهای زیر در نام فایل ظاهر شوند: backspace (BS, \b, 0x08)
زبانه افقی (HT، \t، 0x09)، خط جدید (NL، \n، 0x0A)، زبانه عمودی (VT، \v،
0x0B)، فید فرم (FF، \f، 0x0C)، و بازگشت بار (CR، \r، 0x0D). پیش فرض به
نادرست اگر تنظیم نشود

توجه داشته باشید که این فیلد دیگر فیلترهای نام فایل را لغو نمی کند. خواهد بود
لازم است به صراحت تنظیم شود shell_safe_names = غلط همچنین. خواهد بود
لازم برای تنظیم dos_filename_required = غلط (پیش فرض) نیز. خواهد بود
لازم برای تنظیم posix_filename_charset = غلط (پیش فرض) نیز.

کاربر باید برای استفاده از جایگزینی ${quote} در همه فایل ها دقت زیادی داشته باشد
نام های موجود در دستورات در پیکربندی پروژه و حتی پس از آن، تعویض
که انتظار دارند لیستی از نام فایل ها با فاصله از هم جدا شده باشد، نتایج نامشخصی خواهد داشت.

allow_non_ascii_filenames = boolean;
این فیلد ممکن است برای اجازه دادن به نام فایل‌هایی با نویسه‌های غیرقابل چاپ استفاده شود
آنها معمولاً این به معنای UTF8 یا مجموعه ای بین المللی از نوعی است.
اگر تنظیم نشده باشد، پیش‌فرض به false می‌رسد.

توجه داشته باشید که این فیلد دیگر فیلترهای نام فایل را لغو نمی کند. خواهد بود
لازم است به صراحت تنظیم شود shell_safe_names = غلط همچنین. خواهد بود
لازم برای تنظیم dos_filename_required = غلط (پیش فرض) نیز. خواهد بود
لازم برای تنظیم posix_filename_charset = غلط (پیش فرض) نیز.

filename_pattern_accept = [ رشته ];
این فیلد برای تعیین لیستی از الگوهای نام فایل های قابل قبول استفاده می شود.
در صورت تنظیم نشدن، پیش‌فرض روی «*» قرار می‌گیرد.

filename_pattern_reject = [ رشته ];
این فیلد برای تعیین لیستی از الگوهای نام فایل های غیرقابل قبول استفاده می شود.

لطفا توجه داشته باشید: Aegis همچنین با سیستم فایل زیربنایی مشورت می کند تا مفهوم آن را مشخص کند
حداکثر اندازه فایل جایی که حداکثر اندازه فایل سیستم فایل کمتر از
حداکثر_طول_نام_فایل، سیستم فایل برنده می شود. این می تواند اتفاق بیفتد، برای مثال، زمانی که شما هستید
با استفاده از سیستم فایل لینوکس UMSDOS، یا زمانی که NFS یک V7 قدیمی را نصب کرده اید
فایل سیستم تنظیمات حداکثر_طول_نام_فایل به 255 در این موارد تغییر نمی کند
این واقعیت که محدودیت های سیستم فایل اساسی بسیار کوچکتر است (به ترتیب 12 و 14).

اگر دایرکتوری های توسعه شما (یا کل پروژه شما) روی سیستم های فایل با نام فایل است
محدودیت ها، یا بخشی از ساخت های ناهمگن در چنین محیطی اتفاق می افتد،
این کمک می کند که به Aegis بگویید آنها چه هستند (با استفاده از پروژه پیکربندی فیلدهای فایل) به طوری که شما
در موقعیتی قرار نگیرید که پروژه بر اساس سهل‌انگیزتر باشد
محیط‌ها، اما با خطاهای مرموز در محیط‌های محدودتر شکست می‌خورد.

اگر دایرکتوری های توسعه شما به طور معمول بر روی یک سیستم فایل لینوکس UMSDOS هستند، این کار را انجام می دهید
احتمالا تنظیم بهتر است dos_filename_required = درست، و همچنین تغییر در
develop_directory_template رشته. توسعه ناهمگن با ویندوزهای مختلف
محیط ها نیز ممکن است به این نیاز داشته باشند.

تغییر دادن la نوع of a پرونده
اگر می خواهید نوع فایل را تغییر دهید (مثلاً از یک آزمایش به یک فایل منبع یا معاون
برعکس) می توانید آن را به عنوان دو تغییر، با استفاده از ابتدا انجام دهید هوا(1) در یک تغییر و سپس
با استفاده از aenf(1) یا aent(1) در یک تغییر دوم، یا می توانید هر دو مرحله را با هم ترکیب کنید
تغییر دادن. به یاد داشته باشید که از هوا -در حال حاضر یا یک گزینه جدید عجیب و غریب دریافت خواهید کرد
قالب فایل

اخطار
La new_test_command در این پروژه پیکربندی فایل اجرا می شود، اگر تنظیم شود. را پروژه_فایل_فرمان
همچنین اجرا می شود، اگر تنظیم شده باشد، و اگر اخیراً یکپارچه سازی وجود داشته باشد. دیدن aepconf(5) برای
اطلاعات بیشتر.

تست روند

هر تغییری باید همراه با آزمایش باشد و این آزمایش ها نیز الزامی است
در برابر دایرکتوری توسعه ساخته شده اجرا شود، و آنها باید عبور کنند. این امر جدید را تضمین می کند
عملکرد با آزمایش هایی برای تأیید صحت آن همراه است، و رفع اشکال هستند
همراه با تست هایی که تایید می کند که باگ برطرف شده است.

رگرسیون تست
آزمون‌ها مانند هر فایل منبع دیگری در نظر گرفته می‌شوند و در خط مبنا و نگهداری می‌شوند
تاریخچه با تمام فایل های منبع دیگر. تست هایی که باید با هر تغییری همراه باشد
انباشته شدن در خط مبنا پروژه، ارائه یک تعریف از عملکرد صحیح برای
خط پایه این تست های انباشته ممکن است با استفاده از دستور "aegis -REGression" اجرا شوند.
برای تأیید اینکه پروژه در نتیجه تغییر «پسرفت» نمی کند.

خط مقدم تست
رفع اشکال برای انجام آزمایشات مورد نیاز است شکست خوردن در مقابل خط پایه پروژه (برعکس
به دایرکتوری توسعه). این تضمین می کند که آزمایش واقعاً اشکال را نشان می دهد
در خط مبنا، و همچنین نشان می دهد که با تغییر ثابت شده است. جدید
عملکرد به طور پیش پاافتاده در برابر خط پایه شکست می خورد، و بنابراین aegis تلاشی برای این کار نمی کند
حدس بزنید اگر یک تست یک تست رفع اشکال یا تست عملکرد جدید باشد، به سادگی نیاز به تست دارد
در برابر خط پایه شکست بخورد.

این الزام هم برای تست های جدیدی که با تغییر ایجاد می شوند و هم برای تست ها اعمال می شود
که برای اصلاح در یک تغییر کپی شده اند.

بررسی تست
داوران ممکن است مطمئن باشند که aegis الزامات آزمون را اجرا کرده است. که یک تغییر
باید آزمایش هایی داشته باشد، که تغییر باید ایجاد شود، که آزمایش ها در برابر توسعه رد شوند
دایرکتوری، و اینکه تست ها در برابر خط پایه شکست می خورند. این شرایط اجرا می شود
by aede(1) و تغییر به پیش نخواهد رفت بودن بررسی دولت تا اینها
شرایط برآورده شده است. بنابراین، داوران باید تست‌های مربوط به آن را بررسی کنند کامل بودن از پوشش
کد موجود در تغییر، و عدم حساسیت به تغییرات در محیط اجرا (مثلاً
به تاریخ حساس نیست). بازبین‌ها همچنین باید از "aegis -list change_details" برای تأیید استفاده کنند
که یک تغییر دارای معافیت های آزمایشی است یا ندارد.

معافیت
ممکن است توسط مدیران پروژه معافیت‌های آزمایشی مختلف اعطا شود aepa(1) و
aepattr(5) برای اطلاعات بیشتر کپی کردن تست ها در یک تغییر یا اضافه کردن تست های جدید به a
تغییر، ممکن است آن معافیت ها را لغو کند.

تست همبستگی ها

دستور "aegis -Test -SUGgest" ممکن است برای پیشنهاد aegis رگرسیون مناسب استفاده شود
بر اساس فایل های منبع موجود در تغییر شما، تغییرات شما را آزمایش می کند. این به صورت خودکار
تلاش تست را بر روی تست های مربوطه متمرکز می کند و تعداد تست های رگرسیون را کاهش می دهد
لازم است مطمئن باشید که اشکالی را معرفی نکرده اید.

همبستگی های تست توسط دستور "aegis -Integrate_Pass" تولید می شوند که
هر تست در تغییر را با هر فایل منبع در تغییر مرتبط می کند. بنابراین، هر یک
فایل منبع فهرستی از تست هایی را که در گذشته با آن مرتبط بوده اند جمع آوری می کند.
این به اندازه تحلیل پوشش کد دقیق نیست، اما یک تقریب معقول در آن است
عمل.

La aecp(1) و aenf(1) از دستورات برای مرتبط کردن فایل ها با یک تغییر استفاده می شود. وقتی آنها
به طور فعال ارتباط را انجام ندهید، اینها فایل هایی هستند که توسط آنها استفاده می شود aeipass(1) و
aet(1) برای تعیین اینکه کدام فایل منبع با کدام آزمایش مرتبط است.

تست ارتباط دقت
با فرض اینکه همبستگی های تست دقیق هستند و تست ها یکنواخت هستند
توزیع شده در سراسر فضای تابع، کمتر از وجود خواهد داشت 1/شماره شانسی که الف
تست مربوطه توسط "aegis -Test -SUGgest" اجرا نشده است عدد” فرمان یک کوچک
مقدار نویز به وزن تست اضافه می شود، به طوری که گاهی اوقات موارد غیر منتظره رخ می دهد
تست شده است و هر بار تست های یکسانی اجرا نمی شود.

دقت همبستگی آزمون را می توان با اطمینان از اینکه:

· هر تغییر باید به شدت متمرکز باشد، بدون درج فایل های رایگان. این
از همبستگی های جعلی جلوگیری می کند.

· هر مورد از عملکرد جدید باید در یک تغییر فردی اضافه شود
چندین با هم این به شدت تست ها را با عملکرد مرتبط می کند.

· هر اشکال باید در یک تغییر فردی، به جای چندین با هم رفع شود. این
به شدت تست ها را با عملکرد مرتبط می کند.

· در صورت جابجایی فایل ها، همبستگی های تست از بین خواهند رفت. این به این دلیل است که همبستگی ها توسط
نام.

بهترین راه برای ارتباط دقیق تست‌ها با فایل‌های منبع، زمانی است که تغییر می‌کند
حاوی یک آزمایش و دقیقاً آن فایل های مربوط به عملکرد مورد آزمایش است. هم
بسیاری از فایل های جعلی سودمندی همبستگی های آزمایشی را ضعیف می کند.

OPTIONS

گزینه های زیر قابل درک است.

-اتوماتیک
این گزینه ممکن است برای تعیین تست های خودکار استفاده شود. تست های خودکار نیازی به هیچ
کمک های انسانی

-BAse_RElative
این گزینه ممکن است برای در نظر گرفتن نام فایل‌های نسبی با آن استفاده شود
پایه درخت منبع دیدن aeuconf(5) برای کاربر مربوطه
ترجیح.

-CUrrent_RElative
این گزینه ممکن است برای در نظر گرفتن نام فایل‌های نسبی با آن استفاده شود
دایرکتوری فعلی این معمولاً پیش فرض است. دیدن aeuconf(5) برای
اولویت کاربر مربوطه

-تغییر دادن عدد
این گزینه ممکن است برای تعیین یک تغییر خاص در یک پروژه استفاده شود. دیدن
حمایت(1) برای توضیح کامل این گزینه.

-کمک
این گزینه ممکن است برای به دست آوردن اطلاعات بیشتر در مورد نحوه استفاده از آن استفاده شود حمایت
برنامه است.

-فهرست
این گزینه ممکن است برای به دست آوردن لیستی از موضوعات مناسب برای این دستور استفاده شود.
فهرست ممکن است کلی تر از حد انتظار باشد.

-کتابچه راهنمای این گزینه ممکن است برای تعیین تست های دستی استفاده شود. آزمایشات دستی به تعدادی انسان نیاز دارد
مداخله، به عنوان مثال: تأیید برخی از رفتارهای صفحه نمایش (مثلاً X11)، یا
برخی از اقدامات کاربر، "اکنون کابل اترنت را جدا کنید".

-Not_Logging
این گزینه ممکن است برای غیرفعال کردن ثبت خودکار خروجی ها و خطاها استفاده شود
یک فایل. این اغلب زمانی مفید است که چندین دستور aegis در یک پوسته ترکیب شوند
اسکریپت

-خروجی نام فایل
این گزینه ممکن است برای تعیین نام فایلی که قرار است با آن نوشته شود استفاده شود
نام فایل آزمایشی به طور خودکار تعیین می شود. برای نوشتن اسکریپت مفید است.

-پروژه نام
این گزینه ممکن است برای انتخاب پروژه مورد علاقه استفاده شود. وقتی نه -پروژه
گزینه مشخص شده است، AEGIS_PROJECT متغیر محیطی مورد بررسی قرار می گیرد. اگر
که وجود ندارد، متعلق به کاربر است $HOME/.aegisrc فایل برای یک پیش فرض بررسی می شود
زمینه پروژه (نگاه کنید به aeuconf(5) برای اطلاعات بیشتر). اگر آن وجود نداشته باشد،
زمانی که کاربر فقط روی تغییرات در یک پروژه کار می کند، پروژه
نام پیش فرض برای آن پروژه است. در غیر این صورت خطا است.

-قالب
این گزینه ممکن است برای تعیین اینکه یک قالب فایل جدید باید استفاده شود، حتی استفاده شود
اگر فایل از قبل وجود داشته باشد.

-No_TEMplate
این گزینه ممکن است برای تعیین اینکه از یک الگوی فایل جدید استفاده نشود، استفاده شود.
حتی اگر فایل وجود نداشته باشد (هر فایل خالی ایجاد خواهد شد).

-ترس
این گزینه ممکن است برای ایجاد فهرست ها برای تولید حداقل مقدار استفاده شود
اطلاعات معمولا برای اسکریپت های پوسته مفید است.

-وبربس
این گزینه ممکن است برای ایجاد خروجی بیشتر aegis استفاده شود. به طور پیش فرض aegis
فقط بر روی خطاها خروجی تولید می کند. هنگام استفاده با -فهرست این گزینه را انتخاب کنید
باعث می شود عنوان ستون اضافه شود.

-صبر کن این گزینه ممکن است برای نیاز به دستورات Aegis برای منتظر ماندن برای قفل دسترسی استفاده شود، اگر
آنها را نمی توان بلافاصله به دست آورد. به طور پیش فرض برای کاربر lock_wait_preference
اگر مشخص نشده است، ببینید aeuconf(5) برای اطلاعات بیشتر

-نه_صبر کن
این گزینه ممکن است برای نیاز به دستورات Aegis برای صدور یک خطای مرگبار در صورت دسترسی استفاده شود
قفل ها را نمی توان فوراً بدست آورد. به طور پیش فرض برای کاربر
lock_wait_preference اگر مشخص نشده است، ببینید aeuconf(5) برای اطلاعات بیشتر

همچنین مشاهده کنید حمایت(1) برای گزینه های مشترک برای همه دستورات aegis.

همه گزینه ها ممکن است به اختصار باشد. مخفف به صورت حروف بزرگ ثبت شده است،
تمام حروف کوچک و زیرخط (_) اختیاری هستند. باید متوالی استفاده کنید
دنباله ای از حروف اختیاری

همه گزینه ها به حروف بزرگ و کوچک حساس نیستند، می توانید آنها را با حروف بزرگ یا کوچک یا a تایپ کنید
ترکیب هر دو، مورد مهم نیست.

به عنوان مثال: آرگومان های "-project، "-PROJ" و "-p" همه به معنای
-پروژه گزینه. استدلال "-prj" درک نخواهد شد، زیرا متوالی است
کاراکترهای اختیاری ارائه نشده است.

گزینه ها و دیگر آرگومان های خط فرمان ممکن است به طور دلخواه در خط فرمان مخلوط شوند،
بعد از انتخابگرهای تابع

نام گزینه های طولانی گنو قابل درک است. از آنجایی که همه نام گزینه ها برای حمایت طولانی هستند،
این به معنای نادیده گرفتن «-» اضافی است. "--انتخاب=ارزش"کنوانسیون نیز است
فهمیده

می شود. آلیاس

نام مستعار توصیه شده برای این دستور است
csh% نام مستعار aent 'aegis -nt \!* -v'
sh$ aent(){aegis -nt "$@" -v}

خطاها

اگر تغییر در آن نباشد خطا است بودن توسعه دولت است.
اگر تغییر به کاربر فعلی اختصاص داده نشود، یک خطا است.

خروج وضعیت

La حمایت دستور با وضعیت 1 در هر خطایی خارج می شود. در حمایت فقط دستور خواهد داد
در صورت عدم وجود خطا با وضعیت 0 خارج شوید.

محیط زیست متغیرها

دیدن حمایت(1) برای لیستی از متغیرهای محیطی که ممکن است بر این دستور تأثیر بگذارد. دیدن
aepconf(5) برای فایل پیکربندی پروژه پروژه_خاص زمینه برای نحوه تنظیم
متغیرهای محیطی برای تمام دستورات اجرا شده توسط Aegis.

با استفاده از خدمات onworks.net از aent آنلاین استفاده کنید