Malfunction while creating a blog post in Persian #924

Closed
opened 2021-04-13 08:13:25 +00:00 by ahangarha · 9 comments
Contributor

Today, again I faced with an issue for making a blog post. I noticed I could make the post by different names but not any of the following:

  • تغییر نام انبوه پرونده و افزودن شماره به ترتیب زمانی
  • تغییر نام انبوه پرونده‌ها و افزودن شماره به اول نام به ترتیب زمانی

If I would make a post with these titles, the post would be made but If I wanted to edit it, the edit page would load half. So body text was not complete and also no other form element would appear after that textbox. So I had to remove the post and make a new one.

Though I could make a post with this title:

  • تغییر نام انبوه پرونده و افزودن شماره

I faced with the same issue long time ago. So I think this issue is not related to any of the recent changes in code base.

Today, again I faced with an issue for making a blog post. I noticed I could make the post by different names but not any of the following: - تغییر نام انبوه پرونده و افزودن شماره به ترتیب زمانی - تغییر نام انبوه پرونده‌ها و افزودن شماره به اول نام به ترتیب زمانی If I would make a post with these titles, the post would be made but If I wanted to edit it, the edit page would load half. So body text was not complete and also no other form element would appear after that textbox. So I had to remove the post and make a new one. Though I could make a post with this title: - تغییر نام انبوه پرونده و افزودن شماره I faced with the same issue long time ago. So I think this issue is not related to any of the recent changes in code base.

@ahangarha Could you paste the article's body here?

@ahangarha Could you paste the article's body here?
Author
Contributor

This is the wholde article:

https://paste.ubuntu.com/p/bhx5wnrKPg/


تغییر نام انبوه پرونده‌ها با افزودن شماره به اول نام

روز گذشته، ویدئوهای یک فهرست پخش را از یوتیوب بارگیری کردم. ۱۱۸ ویدئو در آن فهرست موجود بود که متاسفانه فاقد شماره سریال بودند. در نتیجه امکان تغییر نام و جابه‌جا کردن شماره سریال از انتها به ابتدای نام پرونده‌ها نبود. بنابراین نیاز بود راهی پیدا کنم باری اینکه پرونده‌ها مرتب و شماره سریالی به اول نام‌شان اضافه کنم. و پیش از ادامه، تاکید کنم که این کار، روی گنولینوکس #اوبونتو انجام شده است.

به لطف مرتب بودن ویدئو در فهرست پخش و اینکه برنامه youtube-dl آن‌ها را به همان ترتیب نمایش در فهرست، دریافت می‌کند، اطمینان داشتم که زمان ایجاد ویدئوها داخل پوشه، مرتب است. بنا بر این، با دستوری مثل ls -tr می‌شد پرونده‌ها را به ترتیب زمانی مشاهده کرد.

از اینجا به بعد کافی بود که بتوانم حلقه‌ای ایجاد کنم و بر اساس محتوای دستور ls نام پرونده‌ها را گفته و شماره‌ای به اول‌شان اضافه کنم. ابتدا به سراغ دستور for‍ رفتم. متاسفانه این دستور اگر به صورت for f in $(ls -tr) استفاده شود، متن را بر حسب فاصله هم از هم تفکیک مي‌کند. در نتیجه در عمل، امکان دریافت نام کامل (در صورتی که در نام پرونده، فاصله وجود داشته باشد) به این روش میسر نبود. لااقل من چیزی روی اینترنت پیدا نکردم.

روش دیگر این بود که ابتدا فهرست مرتب شده را با ls ایجاد کنم و سپس خروجی‌اش را به دستور دیگری مثل while read f بدهم. خوشبختانه این دستور به دلیل خواندن خط به خط، مشکل بالا را حل می‌کرد و به این ترتیب، نام هر پرونده را می‌توانستم در متغیر $f داشته باشم.

الان تنها کاری که لازم بود انجام شود، ایجاد یک متغیر برای شمارش و درج آن در اول نام پرونده و افزایش آن در هر بار پردازش داخل حلقه بود. برای اطمینان از این که تعداد رقم‌ها در شماره با هم برابر است و اولین ویدئو به صورت 001 نام‌گذاری می‌شود نه 1، از دستور قالب‌دهی به متن به این شکل استفاده کردم:

$(printf "%03d" $counter)

تغییر نام هم که با دستوری مثل rename به راحتی قابل انجام است. (البته من از rename روی اوبونتو استفاده می‌کنم که با rename روی برخی توزیع‌های گنولینوکسی دیگر مانند CentOS متفاوت است.) قبل از تغییر نام پرونده‌ها و تا رسیدن به نتیجه مطلوب، از گزینه n در این دستور استفاده می‌کنم که بدون تغییر نام، فقط بگوید که تغییر نام پرونده‌ها به چه شکل خواهد بود. نتیجه، چیزی شبیه به این می‌شود:

counter=1

ls -tr *.mp4 | while read name; do
    rename -n "s//$(printf \"%03d\" $counter) - /" "$name"
    counter=$((counter+1))
done

خروجی‌اش هم چیزی شبیه به این باید باشد:

rename(video first.mp4, "001" - video first.mp4)
rename(video second.mp4, "002" - video first.mp4)
...
rename(video last.mp4, "118" - video last.mp4)

و چون نتیجه، همان چیزی است که من می‌خواستم دستور را بدون گزینه n اجرا کردم. در نتیجه، به راحتی ۱۱۸ پرونده بدون شماره، دارای شماره شدند تا بتوان به راحتی ترتیب‌شان را دید. دستورات نهایی به این شرح‌اند:

counter=1

ls -tr *.mp4 | while read name; do
    rename "s//$(printf \"%03d\" $counter) - /" "$name"
    counter=$((counter+1))
done

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

This is the wholde article: https://paste.ubuntu.com/p/bhx5wnrKPg/ ------- # تغییر نام انبوه پرونده‌ها با افزودن شماره به اول نام روز گذشته، ویدئوهای یک فهرست پخش را از یوتیوب بارگیری کردم. ۱۱۸ ویدئو در آن فهرست موجود بود که متاسفانه فاقد شماره سریال بودند. در نتیجه امکان تغییر نام و جابه‌جا کردن شماره سریال از انتها به ابتدای نام پرونده‌ها نبود. بنابراین نیاز بود راهی پیدا کنم باری اینکه پرونده‌ها مرتب و شماره سریالی به اول نام‌شان اضافه کنم. و پیش از ادامه، تاکید کنم که این کار، روی گنولینوکس #اوبونتو انجام شده است. به لطف مرتب بودن ویدئو در فهرست پخش و اینکه برنامه [youtube-dl](https://youtube-dl.org) آن‌ها را به همان ترتیب نمایش در فهرست، دریافت می‌کند، اطمینان داشتم که زمان ایجاد ویدئوها داخل پوشه، مرتب است. بنا بر این، با دستوری مثل `ls -tr` می‌شد پرونده‌ها را به ترتیب زمانی مشاهده کرد. از اینجا به بعد کافی بود که بتوانم حلقه‌ای ایجاد کنم و بر اساس محتوای دستور `ls` نام پرونده‌ها را گفته و شماره‌ای به اول‌شان اضافه کنم. ابتدا به سراغ دستور `for‍` رفتم. متاسفانه این دستور اگر به صورت `for f in $(ls -tr)` استفاده شود، متن را بر حسب فاصله هم از هم تفکیک مي‌کند. در نتیجه در عمل، امکان دریافت نام کامل (در صورتی که در نام پرونده، فاصله وجود داشته باشد) به این روش میسر نبود. لااقل من چیزی روی اینترنت پیدا نکردم. روش دیگر این بود که ابتدا فهرست مرتب شده را با `ls` ایجاد کنم و سپس خروجی‌اش را به دستور دیگری مثل `while read f` بدهم. خوشبختانه این دستور به دلیل خواندن خط به خط، مشکل بالا را حل می‌کرد و به این ترتیب، نام هر پرونده را می‌توانستم در متغیر `$f` داشته باشم. الان تنها کاری که لازم بود انجام شود، ایجاد یک متغیر برای شمارش و درج آن در اول نام پرونده و افزایش آن در هر بار پردازش داخل حلقه بود. برای اطمینان از این که تعداد رقم‌ها در شماره با هم برابر است و اولین ویدئو به صورت 001 نام‌گذاری می‌شود نه 1، از دستور قالب‌دهی به متن به این شکل استفاده کردم: ```bash $(printf "%03d" $counter) ``` تغییر نام هم که با دستوری مثل rename به راحتی قابل انجام است. (البته من از rename روی اوبونتو استفاده می‌کنم که با rename روی برخی توزیع‌های گنولینوکسی دیگر مانند CentOS متفاوت است.) قبل از تغییر نام پرونده‌ها و تا رسیدن به نتیجه مطلوب، از گزینه `n` در این دستور استفاده می‌کنم که بدون تغییر نام، فقط بگوید که تغییر نام پرونده‌ها به چه شکل خواهد بود. نتیجه، چیزی شبیه به این می‌شود: ```bash counter=1 ls -tr *.mp4 | while read name; do rename -n "s//$(printf \"%03d\" $counter) - /" "$name" counter=$((counter+1)) done ``` خروجی‌اش هم چیزی شبیه به این باید باشد: ``` rename(video first.mp4, "001" - video first.mp4) rename(video second.mp4, "002" - video first.mp4) ... rename(video last.mp4, "118" - video last.mp4) ``` و چون نتیجه، همان چیزی است که من می‌خواستم دستور را بدون گزینه `n` اجرا کردم. در نتیجه، به راحتی ۱۱۸ پرونده بدون شماره، دارای شماره شدند تا بتوان به راحتی ترتیب‌شان را دید. دستورات نهایی به این شرح‌اند: ```bash counter=1 ls -tr *.mp4 | while read name; do rename "s//$(printf \"%03d\" $counter) - /" "$name" counter=$((counter+1)) done ``` این را نوشتم که بعدا برای خودم قابل ارجاع و استفاده مجدد باشد. موارد زیادی پیش می‌آید که نیاز به چنین کاری پیدا مي‌کنم. امیدوارم به درد دیگران هم بخورد. من، دانش محدودی در نوشتن کدهای شل دارم. لذا چیزی که نوشتم الزاما بهترین راه‌حل نیست. اگر راه بهتر و آسان‌تری برای این کار می‌شناسید، لطفا هم‌رسانی کنید.

Thanks!

Thanks!
Author
Contributor

I had the same issue today again. This is the article:

title:

چند سؤال پیرامون نمودار مرگ در ایران در سال‌های ۲۰۱۸ تا ۲۰۲۰

body:

چندی پیش، نموداری از میزان مرگ و میر در ایران طی سال‌های ۲۰۱۸ تا پایان ۲۰۲۰ منتشر شد. کاوه مدنی و ماهان غفاری برای اساس ارقام موجود در آن نمودار، افزایش مرگ و میر در دسامبر ۲۰۱۹ را مرتبط با کشتار آبان ۹۸ دانستند و از آن به نوعی نتیجه گرفتند که تعداد کشته‌ها، به مراتب بیش از چیزی بوده که تخمین زده می‌شده است. ابهاماتی در خصوص داده‌ها و امکان استنتاج چنان نتیجه‌ای از آن اطلاعات در ذهنم ایجاد شده است که اینجا آن‌ها را منتشر می‌کنم.

عکس

نظر به فضای حاکم بر جامعه در خصوص فاجعه آبان ۹۸، متأسفانه لازم به ذکر است که این مقاله لااقل در این مرحله، تلاشی برای رد ارتباط افزایش نرخ مرگ و میر در تاریخ مربوطه با کشتار مردم ندارد. این مقاله تلاش می‌کند بررسی کند آیا بر اساس این میزان داده و با این کیفیت، آیا می‌توان نتیجه‌ای گرفت یا خیر. در حقیقت، این مقاله، سؤالاتی را در مقابل طرح کنندگان مساله قرار می‌دهد بدون اینکه خودش در مقام اثبات چیزی باشد.

## میزان داده‌ها

چالش اول، میزان داده‌هاست. همان‌طور که در بخش سمت چپ نمودار دیده می‌شود، نوسانات این نمودار بیش از چیزی است که بتوان در آن روند یا الگویی مشاهده کرد که به لحاظ آماری قابل استناد باشد. در مجموع ۲۹ مورد داده‌های مرگ و میر دیده می‌شود که به‌خصوص به دلیل نداشتن الگویی پایدار (جز در قسمت پایانی) امکانی برای انجام تحلیلی علمی در اختیار محقق و تحلیل‌گر قرار نمی‌دهد. دسترسی و بررسی هم‌زمان داده‌های بیشتر، برای داشتن امکان تحلیل ضروری است.

## نوسانات طبیعی مرگ و میز در پاییز و زمستان

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

نکته‌ای که می‌توان از نمودارهای متعدد مرگ و میر بر اثر آنفولانزا به دست آورد، نوسانات شدید در بیشینه میزان مرگ میر در سال‌های مختلف است. افزایش مرگ و میر بر اثر آلودگی هوا را نیز می‌توان به این آمار فصلی اضافه کرد. با این اوصاف، ضرورت دارد که میزان مرگ و میر در ماه‌های نوابر و دسامبر سال‌های قبل‌تر هم بررسی شود تا مشخص شود میزان مرگ و میر در این فصل در چه بازه‌ای از اعداد طبیعی (یا به تعبیر آماری، نرمال) است. لذا با این میزان داده، بالا بودن آمار مرگ و میر در نوابر ۲۰۱۹، تنها به این دلیل که از سایر اعداد در نمودار بیشتر است نمی‌تواند معنی خاصی داشته باشد.

## کیفیت داده

با نگاهی به دو رقم آخر اعداد می‌بینیم که تا پیش از فروردین ۹۹، دو رقم آخر بین ۱۳، ۱۴، ۱۵ و ۱۶ تغییر می‌کنند که به هیچ عنوان طبیعی نیست. بررسی دقیق مقادیر، موضوع عجیب‌تری را نشان می‌دهد. احتمال تکرار یک عدد پنج‌رقمی در یک مجموعه ۲۹ عضوی، بسیار ناچیز است. حتی اگر یک بازه ۱۰ هزار واحدی را در نظر بگیریم برای نوسانات، احتمال دو بار تکرار یک عدد، یک ده‌هزارم می‌شود. این در حالی است که در نمودار فوق، به کرات اعداد تکرار می‌بینیم. تنها در چهار ماه مختلف، میزان مرگ و میر عدد ۳۳۶۱۵ ثبت شده است که می‌توان گفت ناممکن است. این دو مساله به خوبی نشان می‌دهد که اعداد و ارقام این نمودار، به ویژه پیش از فروردین ۹۹ به شدت مخدوش و غیرطبیعی است.

## رفتار نمودار

مساله دیگر، تفاوت فاحش رفتار نمودار پیش و پس از فروردین ۹۹ است. این مساله به شدت نیازمند بررسی توسط متخصصین پزشکی است. اما قدری غیرطبیعی به نظر می‌رسد که نموداری با نوسانات شدید تا پیش از فروردین ۹۹، ناگهان رفتاری ملایم از خود نشان دهد.

## جمع‌بندی

همان‌طور که در ابتدای نوشته هم گفته شد، این مقاله تلاشی برای اثبات عدم ارتباط افزایش مرگ و میر در نوابر ۲۰۱۹ با کشتار آبان ۹۸ ندارد. بلکه در مواردی که ذکر شد، ابهاماتی را در خصوص اصالت داده‌ها و نتیجه‌گیری از آن به‌خصوص برای برآورد تعداد کشته‌شدگان در آن ماه طرح کرده است. این نوشته به دنبال یافتن پاسخ این سؤال است که با چه ابزار علمی و مستدلی می‌توان از داده‌های محدود و مخدوش این نمودار، نتیجه‌گیری خاصی به دست داد.
I had the same issue today again. This is the article: ## title: چند سؤال پیرامون نمودار مرگ در ایران در سال‌های ۲۰۱۸ تا ۲۰۲۰ ## body: ``` چندی پیش، نموداری از میزان مرگ و میر در ایران طی سال‌های ۲۰۱۸ تا پایان ۲۰۲۰ منتشر شد. کاوه مدنی و ماهان غفاری برای اساس ارقام موجود در آن نمودار، افزایش مرگ و میر در دسامبر ۲۰۱۹ را مرتبط با کشتار آبان ۹۸ دانستند و از آن به نوعی نتیجه گرفتند که تعداد کشته‌ها، به مراتب بیش از چیزی بوده که تخمین زده می‌شده است. ابهاماتی در خصوص داده‌ها و امکان استنتاج چنان نتیجه‌ای از آن اطلاعات در ذهنم ایجاد شده است که اینجا آن‌ها را منتشر می‌کنم. عکس نظر به فضای حاکم بر جامعه در خصوص فاجعه آبان ۹۸، متأسفانه لازم به ذکر است که این مقاله لااقل در این مرحله، تلاشی برای رد ارتباط افزایش نرخ مرگ و میر در تاریخ مربوطه با کشتار مردم ندارد. این مقاله تلاش می‌کند بررسی کند آیا بر اساس این میزان داده و با این کیفیت، آیا می‌توان نتیجه‌ای گرفت یا خیر. در حقیقت، این مقاله، سؤالاتی را در مقابل طرح کنندگان مساله قرار می‌دهد بدون اینکه خودش در مقام اثبات چیزی باشد. ## میزان داده‌ها چالش اول، میزان داده‌هاست. همان‌طور که در بخش سمت چپ نمودار دیده می‌شود، نوسانات این نمودار بیش از چیزی است که بتوان در آن روند یا الگویی مشاهده کرد که به لحاظ آماری قابل استناد باشد. در مجموع ۲۹ مورد داده‌های مرگ و میر دیده می‌شود که به‌خصوص به دلیل نداشتن الگویی پایدار (جز در قسمت پایانی) امکانی برای انجام تحلیلی علمی در اختیار محقق و تحلیل‌گر قرار نمی‌دهد. دسترسی و بررسی هم‌زمان داده‌های بیشتر، برای داشتن امکان تحلیل ضروری است. ## نوسانات طبیعی مرگ و میز در پاییز و زمستان هر چند بنا به دلیلی که بالا گفته شد نمی‌توان از خود این نمودار استنباط مشخصی کرد اما به لحاظ عقلی و همچنین به استناد آمارهای مرگ و میر بر اثر بیماری‌های فصلی می‌توان درک کرد که هر سال در نیمه دوم پاییز، آمار مرگ و میر بر اثر بیماری‌های همچون آنفولانزا افزایش یابد. نکته‌ای که می‌توان از نمودارهای متعدد مرگ و میر بر اثر آنفولانزا به دست آورد، نوسانات شدید در بیشینه میزان مرگ میر در سال‌های مختلف است. افزایش مرگ و میر بر اثر آلودگی هوا را نیز می‌توان به این آمار فصلی اضافه کرد. با این اوصاف، ضرورت دارد که میزان مرگ و میر در ماه‌های نوابر و دسامبر سال‌های قبل‌تر هم بررسی شود تا مشخص شود میزان مرگ و میر در این فصل در چه بازه‌ای از اعداد طبیعی (یا به تعبیر آماری، نرمال) است. لذا با این میزان داده، بالا بودن آمار مرگ و میر در نوابر ۲۰۱۹، تنها به این دلیل که از سایر اعداد در نمودار بیشتر است نمی‌تواند معنی خاصی داشته باشد. ## کیفیت داده با نگاهی به دو رقم آخر اعداد می‌بینیم که تا پیش از فروردین ۹۹، دو رقم آخر بین ۱۳، ۱۴، ۱۵ و ۱۶ تغییر می‌کنند که به هیچ عنوان طبیعی نیست. بررسی دقیق مقادیر، موضوع عجیب‌تری را نشان می‌دهد. احتمال تکرار یک عدد پنج‌رقمی در یک مجموعه ۲۹ عضوی، بسیار ناچیز است. حتی اگر یک بازه ۱۰ هزار واحدی را در نظر بگیریم برای نوسانات، احتمال دو بار تکرار یک عدد، یک ده‌هزارم می‌شود. این در حالی است که در نمودار فوق، به کرات اعداد تکرار می‌بینیم. تنها در چهار ماه مختلف، میزان مرگ و میر عدد ۳۳۶۱۵ ثبت شده است که می‌توان گفت ناممکن است. این دو مساله به خوبی نشان می‌دهد که اعداد و ارقام این نمودار، به ویژه پیش از فروردین ۹۹ به شدت مخدوش و غیرطبیعی است. ## رفتار نمودار مساله دیگر، تفاوت فاحش رفتار نمودار پیش و پس از فروردین ۹۹ است. این مساله به شدت نیازمند بررسی توسط متخصصین پزشکی است. اما قدری غیرطبیعی به نظر می‌رسد که نموداری با نوسانات شدید تا پیش از فروردین ۹۹، ناگهان رفتاری ملایم از خود نشان دهد. ## جمع‌بندی همان‌طور که در ابتدای نوشته هم گفته شد، این مقاله تلاشی برای اثبات عدم ارتباط افزایش مرگ و میر در نوابر ۲۰۱۹ با کشتار آبان ۹۸ ندارد. بلکه در مواردی که ذکر شد، ابهاماتی را در خصوص اصالت داده‌ها و نتیجه‌گیری از آن به‌خصوص برای برآورد تعداد کشته‌شدگان در آن ماه طرح کرده است. این نوشته به دنبال یافتن پاسخ این سؤال است که با چه ابزار علمی و مستدلی می‌توان از داده‌های محدود و مخدوش این نمودار، نتیجه‌گیری خاصی به دست داد. ```
KitaitiMakoto added the
Rendering
label 2022-01-02 18:15:34 +00:00
KitaitiMakoto added this to the 0.8.0 milestone 2022-01-02 18:15:39 +00:00

hmmm... the issue might be in Rocket.

hmmm... the issue might be in Rocket.

Someone truncates response body to 8270 bytes... Rocket...hyper...or else.

Someone truncates response body to 8270 bytes... Rocket...hyper...or else.

rocket_csrf seems doing something because this problem's away if I remove it.

I'm upgrading it for Rocket 0.5. So, after that upgrading, I will work with this issue again.

rocket_csrf seems doing something because this problem's away if I remove it. I'm upgrading it for Rocket 0.5. So, after that upgrading, I will work with this issue again.

This is actually a bug of rocket_csrf: plume/rocket_csrf#10

This is actually a bug of rocket_csrf: https://git.joinplu.me/plume/rocket_csrf/pulls/10

I found the cause and fixed it at last! It will be included in the next release.

I found the cause and fixed it at last! It will be included in the next release.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Plume/Plume#924
No description provided.