সতর্কতা বা ত্রুটি দেখা দিলে প্রোগ্রামের নাম আউটপুট করা উচিত?

13

আমি যদি কোনও স্ক্রিপ্ট বা কোনও প্রোগ্রাম লিখছি, আমি কি সতর্কতা বা ত্রুটি বার্তার সাথে একত্রে এর নামটি স্ট্রার্ড করতে পারি? উদাহরণ স্বরূপ:

./script.sh: Warning! Variable "var" lowered down to 10.

বা:

./prog.py: Error! No such file: "file.cfg".

আমি বুঝতে পারি যে এটি সাধারণত স্বাদের বিষয় (বিশেষত যদি আপনি নিজের নিজের জিনিস নিজের জন্য লেখেন) তবে আমি অবাক হয়েছি যে এর মধ্যে প্রচলিত কিছু আছে কি না? আমি বিশ্বাস করি বেশিরভাগ ইউএনআইএক্স / লিনাক্স ইউটিলিটিগুলি যখন কিছু ঘটে তখন তাদের নাম লেখেন, সুতরাং এটি একটি ভাল জিনিস বলে মনে হয় তবে কীভাবে এটি করবেন এবং কীভাবে করবেন না এমন কোনও গাইডলাইন বা অব্যক্ত নিয়ম রয়েছে?

উদাহরণস্বরূপ, বাইনারি ইনস্টল করার পরামর্শ দেওয়া হয় না /usr/bin/, বরং এর অধীনে /usr/local/bin/বা অন্য কোনও কিছুতে। স্টারডার থেকে আউটপুট সম্পর্কে কি একই রকম নিয়ম রয়েছে? আমি কি কর্নেলের পরে নাম লিখব? বা কেবল "সতর্কতা!" এবং "ত্রুটি!" শব্দ? আমি কিছুই খুঁজে পাইনি তবে সম্ভবত কেউ আমাকে এটি সম্পর্কে কোথায় পড়তে হবে তা নির্দেশ করতে পারে।

এই প্রশ্নটি প্রোগ্রামিং অনুশীলনগুলি সম্পর্কে কিছুটা, তবে আমি স্ট্যাকওভারফ্লো না করে এখানে এটি বেশি উপযুক্ত বলে মনে করি , কারণ এটি ইউনিক্স / লিনাক্সের traditions তিহ্য সম্পর্কে এবং সাধারণভাবে প্রোগ্রামিং নয়।

stderr unix-philosophy

— gsarret
সূত্র

5

প্রোগ্রামের নামটি no such fileকোনও foo | bar | bazপাইপলাইনে কী প্রোগ্রামটি জানে তার থেকে এলোমেলো ডিবাগ করতে সহায়তা করতে পারে ।

— 116 ট্রিগার করুন

@ থ্রিজ ধন্যবাদ, ভাল পয়েন্ট। আমার পাইপ দেওয়ার কথা নয়, তবে কে জানে। অনুমান করুন মানসম্মত আচরণে আটকে থাকা আরও ভাল।

— গাসারেট

16

একটি সি প্রোগ্রামে পাস করা 0 তম আর্গুমেন্ট সংরক্ষণ করা এবং সাধারণ প্রোগ্রামগুলির mainজন্য এটি প্যারামিটার হিসাবে ব্যবহার করা সাধারণ অনুশীলন perror:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
    char *foo = malloc(9999999999L);
    if (foo == 0)
        perror(argv[0]);
    return 0;
}

সেই প্রোগ্রামটিকে "foo" বলুন, এবং এটি চালানো মূল বিষয়টিকে চিত্রিত করে:

> ./foo
./foo: Cannot allocate memory

জটিল প্রোগ্রামগুলি পাঠ্যে যোগ করতে পারে (বা পথ ছাড়াই কেবলমাত্র ফাইলের নাম ব্যবহার করুন), তবে প্রোগ্রামটির নাম রাখা আপনাকে কোনও দুর্ব্যবহার প্রোগ্রামটি কোথা থেকে এসেছে তা সন্ধান করতে দেয়।

ত্রুটি বার্তাগুলির জন্য সর্বজনীনভাবে গৃহীত কোনও স্কিম নেই, তবে কিছু বিস্তৃত ব্যবহৃত প্রোগ্রাম (যেমন জিসিসি) "ত্রুটি" বা "সতর্কতা" এর মতো একটি বার্তা বিভাগ যুক্ত করে। এখানে আমার বিল্ড-লগগুলির একটি উদাহরণ:

compiling fld_def (obj_s)
../form/fld_def.c: In function '_nc_Copy_Argument':
../form/fld_def.c:164:14: warning: cast discards 'const' qualifier from pointer target type [-Wcast-qual]
        res = (TypeArgument *)argp;
              ^

এই উদাহরণে, জিসিসি ফাইলগুলির নাম, লাইন নম্বর, কলাম নম্বর - এবং আসল বার্তার আগে একটি বিভাগ "সতর্কতা" যুক্ত করে কলোন দিয়ে ক্ষেত্রগুলি পৃথক করে। তবে বেশ কয়েকটি প্রকরণ রয়েছে যা প্রোগ্রামগুলি (যেমন vi-like-emacs ) এর জন্য তথ্যটি বিশ্লেষণকে জটিল করে তোলে ।

সংকলকগুলির জন্য, বার্তায় একটি বিভাগ ব্যবহার করা মারাত্মক ত্রুটিগুলি (যা অবিলম্বে মারাত্মক হতে পারে না ) এবং সতর্কতাগুলি সনাক্ত করা সহজ করে তোলে । যদি আপনার প্রোগ্রামটি কোনও ত্রুটি থেকে বেরিয়ে আসে তবে এটি বেশি কিছু যোগ করে না যে কিছু সত্যই সতর্কতা এবং কিছুতে ত্রুটি। তবে যখন এটি আলাদাভাবে আচরণ করে (বা আরও বা কম কাজ করা চালিয়ে যায়) বিভাগটি সম্মুখীন হওয়া সমস্যাটি নির্ণয় করতে সহায়তা করে।

— টমাস ডিকি
সূত্র

একটি উদাহরণের জন্য আপনাকে ধন্যবাদ, আমি পয়েন্ট পেতে। "ত্রুটি" এবং "সতর্কতা" সম্পর্কে কী, তারা কি আউটপুট আটকায়?

— gsarret

আপনার শেষ সম্পাদনা - আমি ঠিক কী সম্পর্কে ভাবছিলাম! যাইহোক ত্রুটিযুক্ত বার্তার পরে ঠিক যদি এটি প্রস্থান করে তবে এর ব্যবহার কী? আবার ধন্যবাদ.

— gsarret

8

যদি কোনও প্রোগ্রাম কোনও স্ক্রিপ্টের অংশ হিসাবে আহ্বান করা হয় যেখানে অন্যান্য অনেকগুলি প্রোগ্রাম আহ্বান করা হয় এবং যদি এটির নামটি মুদ্রণ না করে তবে ব্যবহারকারীরা ত্রুটিটি কোথা থেকে আসছে তা নির্ধারণ করতে খুব কঠিন (er) খুঁজে পাবেন।

(ত্রুটিটি যদি কিছু অপ্রত্যাশিত অভ্যন্তরীণ শর্ত হয় যার জন্য ডিবাগিংয়ের প্রয়োজন হতে পারে তবে আপনি আরও বেশি তথ্য চান: কেবলমাত্র প্রোগ্রামের নাম নয়, একটি উত্স ফাইল এবং লাইন নম্বর এবং সম্ভবত একটি ব্যাকট্র্যাস))

— Kaz
সূত্র

ধন্যবাদ। আমি সাধারণত নিজের জন্য প্রোগ্রাম লিখি (সংখ্যার সিমুলেশন) সুতরাং কেবলমাত্র একজন ব্যবহারকারী আছে তবে আমি সেগুলি একদিন ভাগ করে নিতে পারি। এগুলিও জটিল নয় (ভাল, কমপক্ষে এখনও) সুতরাং ত্রুটির উত্স খুঁজে পেতে কোনও সমস্যা নেই, তবে ইঙ্গিতটির জন্য ধন্যবাদ, ভবিষ্যতে কার্যকর হতে পারে।

— gsarret