عودة النقل المطلوبة عند الطباعة إلى وحدة التحكم في ويندوز؟

Question

يبدو الأمر وكأنه مجرد وضع خط طول جيد بما فيه الكفاية، لكنني أعلم أنه من المفترض أن يكون العائد نقل + خط الأعلاف. هل يحدث أي شيء فظيع إذا كنت لا تضع عودة النقل وتستخدم فقط موجزات الخط فقط؟

هذا في ANSI C وعدم إعادة توجيهك إلى ملف أو أي شيء آخر. مجرد تطبيق وحدة التحكم العادية.

Answer 1

تتبع وحدة تحكم Windows نفس اتفاقية نهاية السطر التي تفترض بالنسبة للملفات، أو في هذه المسألة للمحطات الفعلية الفعلية والمخصصات. يحتاج إلى رؤية كل من CR و LF للانتقال بشكل صحيح إلى السطر التالي.

ومع ذلك، هناك الكثير من البنية التحتية للبرامج بين برنامج ANSI C وهذه وحدة التحكم. على وجه الخصوص، ستحاول أي وظيفة I / O Library القياسية للقيام بالشيء الصحيح، على افتراض أنك سمحت لها الفرصة. هذا هو السبب fopen()'س t و b المعدلات ل mode تم تعريف المعلمة.

مع t (الافتراضي لمعظم التدفقات، وخاصة ل stdin و stdout) ثم أي \n يتم تحويل المطبوعة إلى تسلسل CRLF، وعكس يحدث للقراءة. لإيقاف هذا السلوك، استخدم b المعدل.

بالمناسبة، يتم توجيه المحطات المعطنة تقليديا إلى صناديق Nix بما في ذلك DEC VT100 المحاكمة بواسطة XterM تحتاج أيضا CR و LF. ومع ذلك، في العالم * NIX، يتم التعامل مع حرف جديد من حرف جديد إلى تسلسل CRLF في برنامج تشغيل الجهاز TTY، بحيث لا يحتاج معظم البرامج إلى معرفة ذلك، و t و b يتم تجاهل المعدلات. في تلك المنصات، إذا كنت بحاجة إلى إرسال واستقبال الأحرف على TTY دون هذا التعديل، فأنت بحاجة إلى البحث عن Stty (1) أو يدعو النظام، يعتمد ذلك على.

إذا كان برنامج ANSI C الخاص بك خلاف ذلك يتجنب مكتبة ج i / o إلى وحدة التحكم (ربما كنت بحاجة إلى الوصول إلى لون حرف وحدة التحكم والسمات الأخرى)، فما إذا كنت بحاجة إلى إرسال CR أو لا تعتمد على مكالمات Win32 API التي تستخدمها لإرسال الأحرف.

Answer 2

إذا كنت في بيئة * NIX N (LETFEED) ربما على ما يرام. إذا كنت في Windows، فلن يتم إعادة توجيه (الآن)، فإن LineFeed هو أيضا موافق، ولكن إذا كان شخص ما في نقطة إعادة توجيهات مرحلة ما، :-(

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

تعرف وحدة التحكم ما يجب إظهاره، لكن المستهلكين قد لا يكونوا سعداء ...

إذا كنت تستخدم C #، فقد تجرب البيئة .NEWLINE "ثابت".

http://msdn.microsoft.com/en-us/library/system.environment.newline.aspx.

إذا كنت حقا في الفانيليا C، فأنت عالق مع r n. :-)

Answer 3

ذلك يعتمد على ما تستخدمه من أجله. لن تعرض بعض البرامج خطوط جيودا بشكل صحيح إذا لم تضع كلاهما \r و \n.

إذا حاولت الكتابة فقط \n قد تعرض بعض البرامج التي تستهلك الملف النصي (أو الإخراج) النص الخاص بك كخط واحد بدلا من خطوط متعددة.

هناك أيضا بعض تنسيقات الملفات والبروتوكولات التي ستكون غير صالحة تماما دون استخدام كليهما \r و \n.

Answer 4

لم أحاول ذلك لفترة طويلة أنني لست متأكدا من أنني أتذكر ما يحدث ... ولكن لا يتنقل نفسه إلى أسفل خط دون العودة إلى العمود الأيسر؟

اعتمادا على برنامج التحويل البرمجي الخاص بك، قد يتم فتح الإخراج القياسي في وضع النص، وفي هذه الحالة سيتم ترجمة سائل واحد إلى r n قبل الكتابة.

يحرر: لقد حاولت فقط اختبار سريع، وفي XP ملف دون إرجاع يعرض بشكل طبيعي. ما زلت لا أعرف ما إذا كان أي مترجم يدخل العائدات لك.

Answer 5

في ج، تأتي الملفات (تسمى "التدفقات") في نكهات - ثنائي أو نص.

يعتمد معنى هذا التمييز على التنفيذ / النظام الأساسي المعتمد، ولكن على Windows (مع تطبيقات شائعة رأيته) عند الكتابة إلى تدفقات النص " n" يترجم تلقائيا إلى " r n"، وعند القراءة من النص تترجم تيارات " r n" تلقائيا إلى " n".

"وحدة التحكم" هي في الواقع "إخراج قياسي"، وهو مجرى مفتوح افتراضيا كدفق نص. لذلك، في الممارسة العملية على Windows، يجب أن تكون "Hello، World! n" كافية للغاية - ومحمولة.