새로운 이슈

Malfunction while creating a blog post in Persian #924

닫힘

ahangarha가 을 오픈 · 9개의 코멘트

ahangarha 코멘트됨,

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.

KitaitiMakoto 코멘트됨,

소유자

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

ahangarha 코멘트됨,

포스터

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 ``` این را نوشتم که بعدا برای خودم قابل ارجاع و استفاده مجدد باشد. موارد زیادی پیش می‌آید که نیاز به چنین کاری پیدا مي‌کنم. امیدوارم به درد دیگران هم بخورد. من، دانش محدودی در نوشتن کدهای شل دارم. لذا چیزی که نوشتم الزاما بهترین راه‌حل نیست. اگر راه بهتر و آسان‌تری برای این کار می‌شناسید، لطفا هم‌رسانی کنید.

KitaitiMakoto 코멘트됨,

소유자

Thanks!

👍 1

ahangarha 코멘트됨,

포스터

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: ``` چندی پیش، نموداری از میزان مرگ و میر در ایران طی سال‌های ۲۰۱۸ تا پایان ۲۰۲۰ منتشر شد. کاوه مدنی و ماهان غفاری برای اساس ارقام موجود در آن نمودار، افزایش مرگ و میر در دسامبر ۲۰۱۹ را مرتبط با کشتار آبان ۹۸ دانستند و از آن به نوعی نتیجه گرفتند که تعداد کشته‌ها، به مراتب بیش از چیزی بوده که تخمین زده می‌شده است. ابهاماتی در خصوص داده‌ها و امکان استنتاج چنان نتیجه‌ای از آن اطلاعات در ذهنم ایجاد شده است که اینجا آن‌ها را منتشر می‌کنم. عکس نظر به فضای حاکم بر جامعه در خصوص فاجعه آبان ۹۸، متأسفانه لازم به ذکر است که این مقاله لااقل در این مرحله، تلاشی برای رد ارتباط افزایش نرخ مرگ و میر در تاریخ مربوطه با کشتار مردم ندارد. این مقاله تلاش می‌کند بررسی کند آیا بر اساس این میزان داده و با این کیفیت، آیا می‌توان نتیجه‌ای گرفت یا خیر. در حقیقت، این مقاله، سؤالاتی را در مقابل طرح کنندگان مساله قرار می‌دهد بدون اینکه خودش در مقام اثبات چیزی باشد. ## میزان داده‌ها چالش اول، میزان داده‌هاست. همان‌طور که در بخش سمت چپ نمودار دیده می‌شود، نوسانات این نمودار بیش از چیزی است که بتوان در آن روند یا الگویی مشاهده کرد که به لحاظ آماری قابل استناد باشد. در مجموع ۲۹ مورد داده‌های مرگ و میر دیده می‌شود که به‌خصوص به دلیل نداشتن الگویی پایدار (جز در قسمت پایانی) امکانی برای انجام تحلیلی علمی در اختیار محقق و تحلیل‌گر قرار نمی‌دهد. دسترسی و بررسی هم‌زمان داده‌های بیشتر، برای داشتن امکان تحلیل ضروری است. ## نوسانات طبیعی مرگ و میز در پاییز و زمستان هر چند بنا به دلیلی که بالا گفته شد نمی‌توان از خود این نمودار استنباط مشخصی کرد اما به لحاظ عقلی و همچنین به استناد آمارهای مرگ و میر بر اثر بیماری‌های فصلی می‌توان درک کرد که هر سال در نیمه دوم پاییز، آمار مرگ و میر بر اثر بیماری‌های همچون آنفولانزا افزایش یابد. نکته‌ای که می‌توان از نمودارهای متعدد مرگ و میر بر اثر آنفولانزا به دست آورد، نوسانات شدید در بیشینه میزان مرگ میر در سال‌های مختلف است. افزایش مرگ و میر بر اثر آلودگی هوا را نیز می‌توان به این آمار فصلی اضافه کرد. با این اوصاف، ضرورت دارد که میزان مرگ و میر در ماه‌های نوابر و دسامبر سال‌های قبل‌تر هم بررسی شود تا مشخص شود میزان مرگ و میر در این فصل در چه بازه‌ای از اعداد طبیعی (یا به تعبیر آماری، نرمال) است. لذا با این میزان داده، بالا بودن آمار مرگ و میر در نوابر ۲۰۱۹، تنها به این دلیل که از سایر اعداد در نمودار بیشتر است نمی‌تواند معنی خاصی داشته باشد. ## کیفیت داده با نگاهی به دو رقم آخر اعداد می‌بینیم که تا پیش از فروردین ۹۹، دو رقم آخر بین ۱۳، ۱۴، ۱۵ و ۱۶ تغییر می‌کنند که به هیچ عنوان طبیعی نیست. بررسی دقیق مقادیر، موضوع عجیب‌تری را نشان می‌دهد. احتمال تکرار یک عدد پنج‌رقمی در یک مجموعه ۲۹ عضوی، بسیار ناچیز است. حتی اگر یک بازه ۱۰ هزار واحدی را در نظر بگیریم برای نوسانات، احتمال دو بار تکرار یک عدد، یک ده‌هزارم می‌شود. این در حالی است که در نمودار فوق، به کرات اعداد تکرار می‌بینیم. تنها در چهار ماه مختلف، میزان مرگ و میر عدد ۳۳۶۱۵ ثبت شده است که می‌توان گفت ناممکن است. این دو مساله به خوبی نشان می‌دهد که اعداد و ارقام این نمودار، به ویژه پیش از فروردین ۹۹ به شدت مخدوش و غیرطبیعی است. ## رفتار نمودار مساله دیگر، تفاوت فاحش رفتار نمودار پیش و پس از فروردین ۹۹ است. این مساله به شدت نیازمند بررسی توسط متخصصین پزشکی است. اما قدری غیرطبیعی به نظر می‌رسد که نموداری با نوسانات شدید تا پیش از فروردین ۹۹، ناگهان رفتاری ملایم از خود نشان دهد. ## جمع‌بندی همان‌طور که در ابتدای نوشته هم گفته شد، این مقاله تلاشی برای اثبات عدم ارتباط افزایش مرگ و میر در نوابر ۲۰۱۹ با کشتار آبان ۹۸ ندارد. بلکه در مواردی که ذکر شد، ابهاماتی را در خصوص اصالت داده‌ها و نتیجه‌گیری از آن به‌خصوص برای برآورد تعداد کشته‌شدگان در آن ماه طرح کرده است. این نوشته به دنبال یافتن پاسخ این سؤال است که با چه ابزار علمی و مستدلی می‌توان از داده‌های محدود و مخدوش این نمودار، نتیجه‌گیری خاصی به دست داد. ```

👍 1

KitaitiMakoto added the

Rendering

label

KitaitiMakoto 0.8.0 마일스톤을 추가하였습니다.

KitaitiMakoto 코멘트됨,

소유자

hmmm... the issue might be in Rocket.

KitaitiMakoto 코멘트됨,

소유자

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

KitaitiMakoto referenced this issue

Edit page don't load completely #1024

KitaitiMakoto 코멘트됨,

소유자

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.

KitaitiMakoto referenced this issue from plume/rocket_csrf

Fix a bug not to proxy Persian content appropriately #10

KitaitiMakoto 코멘트됨,

소유자

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

KitaitiMakoto referenced a pull request that will close this issue

Fix #924 Update rocket_csrf #1116

KitaitiMakoto " 커밋 에서 이 이슈 언급"

Merge pull request 'Fix #924 Update rocket_csrf' (#1116) from update-rocket_csrf into main

KitaitiMakoto closed this issue

KitaitiMakoto 코멘트됨,

소유자

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

로그인하여 이 대화에 참여

마일스톤 없음

담당자 없음

참여자 2명

알림

마감일

기한이 올바르지 않거나 범위를 벗어났습니다. 'yyyy-mm-dd'형식을 사용해주십시오.

마감일이 설정되지 않았습니다.

의존성

No dependencies set.

불러오는 중...

아직 콘텐츠가 없습니다.

레이블 마일스톤

Malfunction while creating a blog post in Persian #924

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

title:

body: