- फ़ोटो फ़ाइलों को alphabetical order में sort करने की कोशिश की गई, लेकिन operating system और file manager के sorting results अलग निकले
- Linux
ls में sorting सही होती है, लेकिन Windows, Google Drive, KDE Dolphin जैसे ज़्यादातर GUI file managers नंबर वाली filenames को संख्यात्मक रूप से समझने वाला “natural sort” लागू करते हैं
- इसकी वजह से
file-10.txt file-9.txt के बाद आने के बजाय अलग तरह से दिख सकता है, यानी पारंपरिक string sorting से अलग परिणाम मिलता है
- असली समस्या यह थी कि दोनों फ़ोनों में filename rules अलग थे: एक में seconds के बाद milliseconds सीधे जुड़े थे, जबकि दूसरे में underscore से अलग किया गया था, इसलिए sorting का आधार बदल गया
- आखिरकार समाधान सिर्फ यही है कि filename convention एक जैसा किया जाए या हर file manager की hidden settings बदली जाएँ; लेखक को इस बात का अफ़सोस है कि “अब कंप्यूटर उपयोगकर्ता के निर्देश से पहले अनुमान लगाने लगे हैं”
पृष्ठभूमि और समस्या की स्थिति
- लेखक अपने पिता के साथ hiking पर गया, दोनों ने अपने-अपने Android फ़ोन से तस्वीरें लीं, और बाद में सभी तस्वीरें एक ही फ़ोल्डर में रखीं
- फ़ोटो filenames का pattern
IMG_YYYYMMDD_HHmmss था, या उसके बाद अतिरिक्त अंक और .jpg जुड़ा होता था
- क्योंकि इन filenames में साल-महीना-तारीख और समय का क्रम था, लेखक ने सोचा कि फ़ाइलों को alphabetical order में sort करने पर वे shooting time के क्रम में आ जाएँगी
- लेकिन Windows PC, Google Drive, KDE Dolphin आदि में एक ही नियम वाली फ़ाइलें भी सही क्रम में sort नहीं हो रही थीं
- उदाहरण: पिता के फ़ोन से ली गई 5:54 वाली फ़ोटो 9:20 वाली फ़ोटो से पहले दिख रही थी, और 12:11 वाली फ़ोटो के बाद कहीं आ रही थी
- Gnome और स्मार्टफ़ोन के अन्य file managers में भी नतीजा यही था
- Linux
ls command में सही क्रम बना रहा, जिससे भ्रम और बढ़ गया
कारण का विश्लेषण
- शुरुआत में लेखक को लगा कि शायद दोनों फ़ोनों में से किसी एक ने underscore (
_) की जगह कोई अजीब character इस्तेमाल किया होगा, लेकिन Linux ls से जाँच करने पर sorting सामान्य मिली
- अलग-अलग Linux distributions और OpenBSD server पर भी
ls सही alphabetical sorting दिखाता रहा
- इसके उलट, कई GUI file managers (Windows, Google Drive, KDE Dolphin आदि) filename में नंबर होने पर उन्हें असली संख्या के आकार के रूप में compare करते हैं
- यानी alphabetical order की जगह natural sorting को default बना दिया जाता है
- Natural sort string के भीतर के अंकों को साधारण characters नहीं बल्कि संख्यात्मक मान की तरह compare करता है
- उदाहरण:
file-9.txt < file-10.txt → इंसानों को अपेक्षित लगने वाला क्रम
- लेकिन पारंपरिक sorting में
1 < 9 होने से file-10.txt पहले आ जाता है
- मगर आजकल के file managers में अगर कोई “number part” हो, तो उस हिस्से को संख्या का वास्तविक मान मानकर 9 को 10 से पहले लाने के लिए ज़बरदस्ती sort किया जाता है
- इससे filename बनाने वाले उपयोगकर्ता की मूल मंशा से अलग क्रम बन सकता है
असली कारण और समाधान
- लेखक के पिता के फ़ोन में milliseconds के अंक seconds के बाद सीधे जुड़ते थे, जबकि लेखक के अपने फ़ोन में underscore से अलग करके लिखे जाते थे
- पिता का फ़ोन: seconds के बाद सीधे milliseconds जोड़ता था → संख्या बड़ी बन जाती थी और पीछे चली जाती थी
- लेखक का फ़ोन: underscore से अलग करता था → उसे अलग string part की तरह माना जाता था
- समाधान: दोनों में से किसी एक तरफ़ के filenames को एक समान pattern में फिर से व्यवस्थित कर दिया जाए, तो समस्या हल हो जाती है
- KDE Dolphin में options के भीतर pure alphabetical sorting चुनी जा सकती है, लेकिन यह setting छिपी हुई है, इसलिए झंझट बढ़ता है
- अलग-अलग programs में यह सुविधा अलग हो सकती है, इसलिए हर बार अलग setting करनी पड़ सकती है
लेखक का निष्कर्ष
- “alphabetical order” चुनने के बावजूद, software उपयोगकर्ता की मंशा का अनुमान लगाकर दूसरी sorting लागू कर दे, इस बात की लेखक ने आलोचना की
- लेखक को पुराने समय की वह सरल शैली याद आती है, जब कंप्यूटर वही करता था जो उसे स्पष्ट रूप से कहा जाता था
1 टिप्पणियां
Hacker News राय
मुझे लगता है कि Microsoft, Google और KDE द्वारा अपनाया गया sorting तरीका ज़्यादा intuitive है और ज़्यादा आम use cases को cover करता है; लेखक की स्थिति बेहद दुर्लभ लगती है। ज़्यादातर लोग चाहते हैं कि “10”, “9” के बाद आए। Desktop environments भी sorting को “alphabetical” नहीं बल्कि “name” के आधार पर बताते हैं, इसलिए गलतफ़हमी नहीं होनी चाहिए। मुझे यह पसंद नहीं कि कंप्यूटर हमारी मंशा पढ़ने की कोशिश करे, लेकिन autosave जैसी चीज़ों की तरह यह असल ज़िंदगी में उपयोगी भी है। सख्त alphabetical sorting का विकल्प होना अच्छा होगा, लेकिन default के रूप में आम मामलों के लिए intuitive व्यवहार सही है।
यह विषय “Worse is better” बहस की याद दिलाता है। लेखक जिस ANSI/Unicode-आधारित simple sorting की माँग कर रहा है, वह असल में केवल कुछ developers के काम की चीज़ है। वास्तव में 99% GUI users intuitive sorting चाहते हैं। Primary users कौन हैं, यह समझना product design को बहुत प्रभावित करता है। बेहतर feature किसी product के लिए सही हो सकता है, लेकिन किसी system के लिए growth और evolution के लिहाज़ से simplicity ज़्यादा उपयुक्त हो सकती है।
Hash value से नाम वाली files ढूँढते समय automatic sorting सबसे ज़्यादा परेशान करती है। Windows में यह उन कुछ options में से है जिन्हें मैं registry से तुरंत बंद कर देता हूँ। कई बार पुराने दिन याद आते हैं जब कंप्यूटर वही करता था जो उससे कहा जाता था। आजकल ऐसा लगता है कि वह “user की मंशा पढ़ने” के बजाय “user की सोच बदलने” की कोशिश कर रहा है, और यह बात खटकती है। Open source सहित, “user ग़लत है” वाली हठी मानसिकता से भी असंतोष है।
abcd89764237औरabcd683426834जैसी चीज़ें नज़र में अजीब जगह पर दिखती हैं, और काफ़ी देर बाद समझ आता है कि ऐसा क्यों है।अगर सब लोग दावा करते हैं कि उन्हें average user की needs पता हैं, तो फिर कोई यह क्यों नहीं कहता कि कंप्यूटर file names को ही अपनी मर्ज़ी से बदल दे? अगर ASCII sorting लागू नहीं करनी, तो extension सहित file names से चिपके रहने की भी ज़रूरत नहीं है। असल में users को jpg, png extensions से फ़र्क नहीं पड़ता, और case distinction की भी परवाह नहीं होती। Windows परिवार में extensions का उपयोग अक्सर पुरानी compatibility की वजह से रहा है। “कंप्यूटर-जैसे file names” थोपते रहना लेकिन “कंप्यूटर-जैसी sorting” को ही तोड़ देना अजीब लगता है। Users क्या चाहते हैं, यह हमें नहीं पता, इसलिए दावे से निष्कर्ष नहीं निकालना चाहिए।
मुझे ज़्यादातर मामलों में लेख में बताई गई version-based sorting बेहतर लगती है। Alphabetical sorting में दिखाना तो bug जैसा महसूस होता है। मेरे हिसाब से समस्या sorting की अवधारणा में नहीं, labeling में है।
sortcommand भी अब version sorting (sort -V) support करता है। अंदर कैसे काम करता है, यह नहीं जानता, लेकिन ज़्यादातर स्थितियों में ठीक चलता है। सबसे अहम बात, इसे आसानी से on/off किया जा सकता है।यहाँ files को “alphabetical” क्रम में sort करने का आदेश नहीं, बल्कि “name” के आधार पर sort करने की बात है, इसलिए इसकी व्याख्या हर OS में अलग हो सकती है। मुझे लगता है कि ज़्यादातर users के लिए जो interpretation बेहतर है, वही logic और data के आधार पर चुनी गई है। शायद भविष्य में ऐसे नियम जुड़ें कि अगर number group में 0 हो तो मूल alphabetical order अपनाया जाए, या user-selection option आ जाए।
macOS Foundation में Finder sorting के लिए इस्तेमाल होने वाला
NSString.localizedStandardCompare()आधिकारिक रूप से दिया गया है। Windows भीStrCompareLogicalदेता है। यानी name sorting, यानी natural sorting, को platforms आधिकारिक रूप से standardize कर रहे हैं।lscommand से अलग होगा, और अब मुझे भी यह तरीका बेहतर लगने लगा है। Photo apps आमतौर पर timestamp के आधार पर sort करती हैं, और अगर किसी file को सच में name order में sort करना हो, तो मैं या तो creation date से sort करूँगा या file names को खुद normalize करूँगा।Unicode report साफ़ तौर पर कहती है कि भाषा और context के अनुसार sorting तरीका बदल सकता है। उदाहरण के लिए, अगर “A-10” को numbers पहचाने बिना alphabetical order में sort करें, तो “A-10”, “A-2” से पहले आएगा। बात जटिल है, लेकिन इसी वजह से file browsers ने natural sorting अपनाई, यह मुझे सही लगता है।
“foo9” को “foo10” से पहले लाने वाला sorting तरीका ही “natural sort” है। हाल ही में Python की 2-line code से natural sorting करना सीखा और बहुत संतोष हुआ। संबंधित Stack Overflow code सुझाता हूँ।
sort(1)command भी natural sorting (-V) support करता है। Image files बनाकरls | sort -Vचलाएँ तो सही काम करता है।du -sh *के output को भीsort -hoption से sort किया जा सकता है।“Image-1.jpg, Image-11.jpg, Image-2.jpg” जैसी मिली-जुली sorting की कमी महसूस नहीं होती। एक समय natural sorting अजीब लगी थी, लेकिन Windows में numbers के हिसाब से sorting होने लगी तो सच में बहुत सुविधा हुई। Files काफ़ी स्वाभाविक क्रम में दिखने लगीं और मैं काफ़ी संतुष्ट था।