फाइल सिस्टम 'File Filesystem' जारी (2021)

 (mgree.github.io)
1 पॉइंट द्वारा GN⁺ 2024-05-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें

ffs: JSON जैसे semi-structured डेटा को UNIX फ़ाइल सिस्टम की तरह माउंट करने वाला टूल

  • ffs का फुल फॉर्म File Filesystem है; यह semi-structured डेटा को फाइलसिस्टम के रूप में माउंट करके आपको परिचित shell टूल्स से JSON, YAML जैसे tree-structured आधुनिक फ़ॉर्मैट्स को संभालने में मदद करता है।
  • sed जैसी string-processing से सीधे JSON edit करना अच्छा तरीका नहीं है, इसलिए ffs को इस्तेमाल करना बेहतर विकल्प हो सकता है।
  • अभी ffs JSON, YAML और TOML को सपोर्ट करता है, और आगे और फ़ॉर्मैट जोड़ने की योजना है।

ffs के उपयोग के उदाहरण

  • ffs [file] कमांड से file.blah को file नामक mount point पर माउंट किया जाता है, और संशोधित अंतिम version stdout पर output होता है।
  • ffs -m MOUNT file से explicit mount point specify किया जा सकता है।
  • ffs -o OUTPUT से output file तय की जा सकती है।
  • ffs -i file से file सीधे edit की जा सकती है, और वॉल्यूम unmount होने पर परिणाम दोबारा file में लिख दिए जाते हैं।
  • edit करते समय nose key की value string की जगह number बन जाती है, और pockets directory object में बदलती दिखाई देती है।

ffs इंस्टॉल करने का तरीका

  • Linux में FUSE की और macOS में macFUSE की जरूरत है।
  • एक single executable को download किया जा सकता है।
  • source से build करना भी संभव है。

ffs के बारे में और जानें

  • PLOS 2021 में "Files-as-Filesystems for POSIX Shell Data Processing" पेपर देखें।
  • demo वीडियो और presentation वीडियो उपलब्ध हैं।

संबंधित टूल तुलना

  • jq, gron आदि CLI में JSON handle करने के लिए अच्छे टूल हैं।
  • ffs की खासियतें हैं: कई फ़ॉर्मैट्स support, परिचित shell tools से सीधे edit करने की सुविधा, और नया भाषा सीखने की जरूरत नहीं।
  • लेकिन Windows support नहीं होना, FUSE इस्तेमाल न हो पाना, केवल search की जरूरत वाले केस, या फाइल का बहुत बड़ा होना जैसी स्थितियों में ffs शायद उपयुक्त नहीं हो।

GN⁺ की राय

  • JSON, YAML, TOML आदि आधुनिक वेब डेवेलपमेंट में व्यापक रूप से उपयोग होने वाले semi-structured डेटा को हैंडल करने में यह उपयोगी लगता है; खासकर shell script से automation करने पर यह काफी powerful हो सकता है।
  • downside यह है कि यह FUSE-based है, इसलिए performance issue आ सकता है, और Windows support का न होना खटकता है। शायद WSL पर चले या नहीं, निश्चित नहीं।
  • open source होने का फायदाः अलग-अलग फ़ॉर्मैट को सपोर्ट करने के लिए योगदान दिया जा सकता है। उपयोगकर्ता के दृष्टिकोण से देखें तो यह convenience और productivity बढ़ा सकता है।
  • यदि आप sed या awk जैसे classic text-processing tools के आदी हैं, तो अतिरिक्त learning cost बिना सीधे अपनाया जा सकता है।
  • API responses को लोकल में save करके debug करने या semi-structured config files को बार-बार edit करने के लिए यह काम का हो सकता है।

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-05-02
Hacker News टिप्पणियाँ

  • मैंने खुद से लिखा गया libfuse Nim में wrap करके 'hello' फाइल सिस्टम उदाहरण को port किया और एक ऐसा संस्करण बनाया जो डेटा को पाइप के जरिए पास करता है और mount point देता है। काम पूरा होने पर परिणाम stdout में लिखता है। इसलिए इसे पाइप चेन में inline चलाया जा सकता है, लेकिन आउटपुट सही तरीके से पकड़ना ज़रूरी है।

  • अभी मैं ऐसे और चीज़ों पर काम कर रहा/रही हूँ जिन्हें फाइल सिस्टम के रूप में बनाया जा सकता है। Nimdow विंडो मैनेजर के लिए मैंने एक स्टेटस बार बनाया, जिसमें हर अलग फाइल में टेक्स्ट लिखने पर ब्लॉक वाले बार के रूप में आउटपुट मिलता है। बार का कंटेंट बदलना बहुत आसान है, इसलिए यह बेहद सुविधाजनक है।

  • मैंने libvlc से एक music player भी बनाया। यह ID3 टैग वाली मीडिया पढ़कर 'By Artist', 'By Album' जैसी फोल्डर स्ट्रक्चर सेट करता है। हर फाइल का नाम '<track number> - <song title>' होता है और उसमें वास्तविक फाइल का पूरा पथ शामिल होता है। किसी गाने को play करने के लिए उन फाइलों में से किसी एक को 'control/current' में cat करना होता है और 'control/command' में शब्द play लिखना होता है। प्लेलिस्ट सपोर्ट व कई और कमांड्स भी हैं, लेकिन बेसिक आइडिया यही है। उद्देश्य है एक हाई-पावर स्क्रिप्टेबल music player बनाना।

  • Unix-like OS में आप disk image mount करके अंदर का content browse कर सकते हैं। लेकिन अंदर की सामग्री खोजने/नेविगेट करने के लिए उपयोगी फाइल फॉर्मैट इससे कहीं ज़्यादा हैं। compressed archive उनमें से एक उदाहरण है। कुछ file manager ये काम करते हैं, लेकिन application layer में इसे implement करना सही abstraction layer नहीं लगता। इसे फाइल-टाइप-विशेष ड्राइवर की तरह implement किया जा सकता है।

  • मैं ऐसे FUSE file system की खोज में हूँ जो mount रहने पर in-memory run हो (tmpfs की तरह) और unmount होने पर disk की एक single file में serialize हो जाए। किसी archive को mount करने वाले FUSE driver से यह सबसे करीब है, लेकिन symbolic link जैसी चीज़ें इसमें नहीं मिल पातीं।

  • Git commit को भी file system की तरह mount किया जा सकता है। (लिंक देखें)

  • Parts-of-file File System भी मौजूद है। (Usenix लिंक देखें)

  • यह मुझे Omar Rizwan की TabFS की याद दिलाता है। (लिंक देखें)

  • ऐसा मैंने 2003 में भी किया था। यह हैरानी की बात है कि यह तेज़ था और fine-grained locking आसानी से बन गई। मैंने इसे एक बड़े वेबसाइट बिल्डिंग टूल के लिए वेब टेम्पलेट लैंग्वेज के per-user database की तरह इस्तेमाल किया था।

  • सवाल ये है कि यदि JSON key में slash हो तो क्या होता है?

  • इससे शायद फाइलों को directory structure के रूप में commit करना संभव हो जाता है। मुझे उत्सुकता है कि इसका merge और conflict पर क्या असर पड़ेगा।

  • यह बहुत बढ़िया लगता है, और जितनी जल्दी हो सके मुझे इसे try करना होगा। लगता है JSON files के अंदर search और navigation के लिए काफी काम का होगा।