Asciinema: الكتابة على القرص في الوقت الحقيقي

التقاط جيدvvv. يبدو أنه يمكن إصلاحه بسهولة إلى حد ما.

نظرت إلى هذا. الأفكار الحالية:

لا تنشئ asciinema دفق JSON سريعًا - فهي تولد سلسلة JSON بأكملها وتحفظها في ملف بمجرد التقاطها بالكامل stdout. هذا في الغالب بسبب كيفية عمل Go's JSON marshaller.

أحد الاحتمالات هو التدفق إلى ملف tmp ( foo.json.tmp إذا قمت بالتسجيل على foo.json ). يمكن أن يبدو مثل:

{ "version": 2, "width": 80, "height": 24, "env": { "TERM": "xterm-256color" } ... }
[0.1, "bash-4.3$ "]
[0.3, "l"]
[0.1, "s"]
...
...

بشكل أساسي ملف JSON به كائنات متعددة ذات مستوى أعلى ، أولاً خريطة JSON مع بيانات وصفية ، وكل ما تبقى يتم طباعته stdout والتي يجب أن تنتهي في النهاية تحت stdout key في الملف النهائي.

بالنسبة للتعافي ، يمكنك بسهولة القيام بذلك بنفسك (فقط تحريك الخطوط في vim).
قد يكون هناك أيضًا أمر جديد asciinema recover foo.json.tmp foo.json لأتمتة هذا (لست متأكدًا مما إذا كان جعل الاسترداد جزءًا من asciinema play هو الأفضل).

أحد الاحتمالات هو التدفق إلى ملف tmp ( foo.json.tmp إذا قمت بالتسجيل على foo.json ).

يبدو جيدا! تشبه هذه الميزة ملفات الحفظ التلقائي لـ Emacs ( #foo.json# ) وملفات استرداد Vim ( .foo.json.swp .)

بالنسبة للتعافي ، يمكنك بسهولة القيام بذلك بنفسك (فقط تحريك الخطوط في vim).

بصراحة ، أنا أفضل أمر "الاسترداد" ، أو حتى الخيار الخفيف -r | --recover ، على العبث اليدوي بملف الحفظ التلقائي.

فقط لتوضيح هذا الأمر بشكل علني ، فإن رقم 82 سيصلح هذه المشكلة أيضًا.

ينطبق xloem # 82 فقط على الحالة عند التسجيل + التحميل إلى asciinema.org في خطوة واحدة. يسمح لك asciinema rec demo.json أيضًا بالتسجيل في ملف دون التحميل تلقائيًا إلى الموقع ، وستكون الكتابة المتزايدة على القرص في هذه الحالة مفيدة بنفس القدر.

لقد بدأت العمل على مسودة بتنسيق asciicast v2 في # 196 ، والتي يجب أن تحل بشكل جيد الكتابة في الوقت الفعلي إلى القرص (والأنابيب ، والشبكة ، ماذا لديك).

رابط مباشر للمستند من هذا العلاقات العامة: https://github.com/asciinema/asciinema/blob/asciicast-v2/doc/asciicast-v2.md

ردود الفعل في غاية الامتنان.

sickill لا أرى كيف ينطبق تغيير تنسيق الملف ( NDJSON بدلاً من JSON) على التحديث المتزايد لملف الإخراج. هل يمكن ان توضح؟

vvv في ملف JSON العادي ، لديك كائن واحد ولا يمكنك الكتابة إليه بشكل تدريجي ، يجب كتابته ككل (من الناحية الفنية يمكنك ذلك ولكن إذا تعطلت وما إلى ذلك ، فستنتهي بملف JSON غير صالح ، ويفتقد الإغلاق اقواس). باستخدام NDJSON (أو JSONLines التي تكون متطابقة تقريبًا) لديك عدة كائنات JSON في ملف واحد ، كل منها في سطر خاص بها. لذلك يمكنك إلحاق أسطر جديدة ببيانات جديدة والتوقف / التعطل حسب الرغبة وعدم ترك الملف غير صالح.

لقد قمت بتحديث مسودة المستند بتنسيق asciicast v2 لتوضيحه بشكل أكبر فيما يتعلق بالتحفيز / المشكلات التي يحلها.

sickill شيء واحد سيكون جيدًا هو تخزين وقت بدء الجلسة في البيانات الوصفية الأولية. يمكن استخراج هذا في أدوات أخرى لتوفير جلسات ssh قابلة للتدقيق.

بالإضافة إلى ذلك ، قد تكون القدرة على "حقن" البيانات الوصفية أمرًا مثيرًا للاهتمام ، لذا يمكنك وضع علامة على جلسة تم إنشاؤها بأشياء مثل:

• المستخدم الذي ssh'd
• اسم المضيف
• بيئة الخادم

وانكشف ذلك في بعض واجهات المستخدم الخارجية.

تحرير: يبدو أن هناك علاقات عامة للتنسيق ، لذلك سأعلق هناك :)

لدي حاليًا برنامج asciinema تم إعداده لتسجيل جلسة الموظفين عن بُعد
الاتصال عبر ssh بشبكة آمنة عبر jumphost. القدرة على الادخار ،
ستؤدي جلسات البث وإعادة التشغيل ، عند حدوثها ، إلى تعزيز
فائدة الوردية في السيناريو المذكور.

يوم الثلاثاء 25 أبريل 2017 الساعة 5:17 صباحًا ، خوسيه دياز غونزاليس <
[email protected]> كتب:

sickill https://github.com/sickill شيء واحد سيكون جيدًا
هو تخزين وقت بدء الجلسة في البيانات الوصفية الأولية.
يمكن استخراج هذا في أدوات أخرى لتوفير جلسات ssh قابلة للتدقيق.

بالإضافة إلى ذلك ، قد تكون القدرة على "حقن" البيانات الوصفية أمرًا مثيرًا للاهتمام ، لذا أنت
من المحتمل أن تضع علامة على جلسة تم إنشاؤها بأشياء مثل:

• المستخدم الذي ssh'd
• اسم المضيف
• بيئة الخادم

وانكشف ذلك في بعض واجهات المستخدم الخارجية.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/asciinema/asciinema/issues/127#issuecomment-296872546 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAi2o-cZFmoJOnPeabG0UkPfb8MVR3EMks5rzVfNgaJpZM4FuWm_
.

أستخدم asciinema (حسنًا ، ليس بعد الآن ، فأنا أعود إلى البرنامج النصي بسبب هذه المشكلة) للاحتفاظ بسجل لجميع الجلسات الطرفية الخاصة بي إلى CYA وكذلك كمرجع إذا نسيت ما فعلته على الخادم X الأسبوع الماضي في الساعة 3 مساء. المشكلة هي أنه نظرًا لأن هذا يتدفق فقط عند عمليات الخروج الناجحة ، فإن نصف جلساتي لا تحتوي على بيانات. إغلاق نافذة لجلسة معلقة على سبيل المثال ، يؤدي إلى خسارة كاملة لتسجيل الجلسة. كان هذا سلوكًا غير متوقع وخيبًا للآمال تمامًا.

يعد تنسيق

sickill - شكرًا لك ، من الجيد سماع هذا. سأراقب ذلك. أفضّل حقًا asciinema على البرنامج النصي لأنه يمكنني تضمين المحتوى في Wiki الخاص بنا لمسؤولي النظام الآخرين.

timofonic يمكنك طرح سؤالك هنا والانتظار بصبر. ليست هناك حاجة لإرسال رسائل غير مرغوب فيها إلى الجميع عن طريق إرسال رسائل ping إلى المستخدمين بهذه الطريقة.

تحديث: تم تنفيذ الكتابة إلى القرص في الوقت الفعلي في # 196 وستكون جزءًا من الإصدار التالي.

إذا كنت ترغب في اختبار الإصدار التجريبي ، فقم بإخراج الفرع develop وتشغيله من دليل الخروج باستخدام: python3 -m asciinema rec filename . أقدر حقًا التعليقات حول كيفية عملها على مختلف توزيعات Linux و macOS

ملاحظة: اعتبارًا من اليوم ، لا يدعم الخادم ومشغل الويب تنسيق asciicast الجديد ، لذا يمكن استخدامه للتسجيل المحلي والتشغيل في المحطة الطرفية فقط.

sickill العمل العظيم! لقد اختبرت هذا للتو وتمكنت من تشغيله (Ubuntu 17.04).

القليل من التوضيح بالرغم من ذلك ؛ ما الذي يسبب مكبات النفايات؟ هل هو ملف التخزين المؤقت أم مهلة؟ في كلتا الحالتين ، ما هي العتبات المحددة؟ سألت ذلك لأنه بعد القيام ببعض الصدى السريع ، لم أر أي شيء في الملف ، لكن عندما لعبت به أكثر ، بدأت الأشياء في الظهور.

metasoarous هذا سؤال رائع.

لا توجد مهلة صريحة أو أي آلية أخرى لتجميع عمليات الكتابة ، فهي تنتقل في الوقت الفعلي من خلال قائمة الانتظار:

https://github.com/asciinema/asciinema/blob/8e1b6f7da1a0ad4d52e63998b14c1a5133fc7836/asciinema/asciicast/v2.py#L72

لفصل عملية "الكاتب":

https://github.com/asciinema/asciinema/blob/8e1b6f7da1a0ad4d52e63998b14c1a5133fc7836/asciinema/asciicast/v2.py#L36 -L40

وهو ما يفعله f.write(...) .

بعد قولي هذا ، لاحظت أيضًا أنه مكتوب في أجزاء 8 كيلوبايت تقريبًا ، لذلك هناك بالتأكيد بعض التخزين المؤقت يحدث هنا. أظن أن Python TextIOWrapper هو المسؤول هنا.

ما رأيك أفضل هنا؟ يمكننا إيقاف التخزين المؤقت على كائن io المفتوح ، أو تنفيذ مشغل صريح ، إما f.flush() في كل عملية كتابة ، أو حساب البايت / الوقت والتدفق عند بلوغ العتبة.

أتخيل أن إيقاف تشغيل التخزين المؤقت على كائن io قد يكون الحل الأسهل ، مع عمليات مسح يدوية كل N ثانية في الثانية. يمكنني أن أتخيل استراتيجيات مربي الحيوانات ، لكن شيئًا قريبًا من أحد هذه الخيارات يجب أن يفي بالغرض.

لقد غيرتها ، لذا فهي الآن تحدد بوضوح سياسة التخزين المؤقت على "التخزين المؤقت للسطر" (== التدفق عند الكتابة يتضمن \n ، وهو الحال بالنسبة لـ 100٪ من عمليات الكتابة في حالتنا) عند فتح الملف للكتابة. إذا قمت بسحبها وجربتها الآن ، فمن المفترض أن ترى الملف ينمو على الفور.

رائع! شكرا جزيلا لاهتمامك السريع!

نظرًا لأن هذا تم تنفيذه (في # 227) وسيتم إصداره مع asciinema 2.0 القادم ، فأنا أغلق هذه المشكلة.

ملاحظة: إذا أراد أي شخص تجربة ذلك ، فقم بإخراج الفرع v2 .