TMP और TEMP दोनों environment variables क्यों मौजूद हैं? (2015)

• Windows में temporary files की location बताने वाले TMP और TEMP दोनों अब भी मौजूद हैं, और जब दोनों अलग हों तो कौन-सा इस्तेमाल होगा यह प्रोग्राम के implementation पर निर्भर करता है
• CP/M में environment variables नहीं थे, इसलिए temporary files की location हर प्रोग्राम में अलग से सेट करनी पड़ती थी, और WordStar जैसे प्रोग्राम executable file के कुछ खास bytes को patch करके behavior बदलते थे
• MS-DOS ने CP/M compatibility को ध्यान में रखते हुए environment variables जोड़े, लेकिन शुरुआती MS-DOS प्रोग्राम पुराने CP/M के प्रभाव के कारण TEMP या TMP का लगभग इस्तेमाल नहीं करते थे
• जब MS-DOS प्रोग्राम environment variables को settings store करने के तरीके के रूप में इस्तेमाल करने लगे, तब TEMP और TMP में प्रतिस्पर्धा शुरू हुई, और DISKCOPY तथा EDIT जैसे कुछ प्रोग्राम TMP से पहले TEMP को देखते थे
• MS-DOS 2.0 के pipe implementation ने temporary file location के लिए TEMP चुना, लेकिन Windows का GetTempFileName पहले TMP को जांचता है, इसलिए दोनों variables साथ-साथ बने रहे

---

TMP और TEMP दोनों बने रहने की पृष्ठभूमि

• Windows environment variables में temporary file location बताने के लिए TMP और TEMP दोनों मौजूद हैं, और अगर दोनों अलग हों तो कौन-सा सही माना जाएगा यह हर प्रोग्राम पर निर्भर करता है
• कोई खास प्रोग्राम temporary files कहाँ बनाएगा, यह उसके implementation पर निर्भर है; Windows प्रोग्राम के GetTempFileName function इस्तेमाल करने की संभावना अधिक होती है, और उस स्थिति में TMP को प्राथमिकता मिलती है
• Environment variables settings dialog में TMP और TEMP दोनों साथ दिखने की वजह यह है कि इनमें से किसी एक को पूरी तरह standard नहीं बनाया गया, और ऐतिहासिक रूप से अलग-अलग विकल्प साथ मौजूद रहे

CP/M में environment variables नहीं थे

• 1973 के आसपास microcomputers में आम operating system CP/M था, और CP/M में environment variables नहीं थे
• Environment variables न होने की वजह से TMP या TEMP environment variables भी मौजूद नहीं थे
• किसी प्रोग्राम में temporary files save करने की location बताने के लिए per-program settings की जरूरत होती थी; executable file के कुछ खास bytes को patch करके वह drive letter तय किया जाता था जहाँ temporary files रखी जाएँ
• WordStar जैसे प्रोग्राम अपने manual में बताते थे कि कौन-से bytes patch करने से कौन-सा behavior बदलेगा, और printer support जैसी custom subroutines जोड़ने के लिए patch space भी देते थे

MS-DOS और environment variables का आगमन

• 1981 में 8086 processor और MS-DOS आए, और दोनों पर CP/M का गहरा प्रभाव था
• MS-DOS के शुरुआती design goals में से एक यह था कि 8080 processor के CP/M programs को 8086 processor के MS-DOS programs में machine translation के जरिए बदला जा सके
• इस translator ने यह मानकर काम किया कि code self-modifying code, instruction के बीच में jump, या code को data की तरह इस्तेमाल करने जैसी अनियमित तकनीकों का उपयोग नहीं करेगा
• 8080 के H और L registers, 8086 के BH और BL registers के अनुरूप थे, और 8080 में calculated address access के लिए केवल HL register इस्तेमाल किया जा सकता था; यही कारण बना कि 8086 में AX, BX, CX, DX में से memory access के लिए केवल BX इस्तेमाल किया जा सकता था
• MS-DOS ने CP/M compatibility के अलावा environment variables जोड़े, लेकिन पुराने CP/M programs environment variables इस्तेमाल नहीं करते थे, इसलिए शुरुआती MS-DOS programs भी उनका उपयोग नहीं करते थे
• Users TEMP या TMP सेट कर सकते थे, लेकिन शुरुआती programs इस पर ध्यान नहीं देते थे

बाजार में TEMP और TMP के बीच प्रतिस्पर्धा

• समय के साथ जब MS-DOS को मुख्य target मानकर programs लिखे जाने लगे, तब programs ने environment variables को settings data store करने के तरीके के रूप में इस्तेमाल करना शुरू किया
• Temporary file location बताने के लिए TEMP और TMP दोनों environment variables इस्तेमाल होने लगे, और दोनों प्रमुख विकल्प बन गए
• किस variable को पहले जांचना है, यह program implementation की पसंद पर निर्भर करता था
• कई programs दोनों को support करने के लिए TEMP और TMP दोनों देखते थे, लेकिन पहले किसे देखें यह implementation के अनुसार बदलता था
• पुराने DISKCOPY और EDIT programs, TMP से पहले TEMP को देखते थे

MS-DOS 2.0 के pipes और TEMP

• MS-DOS 2.0 ने एक program के output को दूसरे program के input में भेजने के लिए pipe feature जोड़ा
• MS-DOS single-tasking operating system था, इसलिए pipes को इस तरह emulate किया गया कि पहले program के output को temporary file में redirect किया जाता, उसे अंत तक चलाया जाता, फिर दूसरे program को उस temporary file को input के रूप में देकर चलाया जाता
• इस feature की वजह से MS-DOS को खुद temporary files बनाने की location की जरूरत पड़ी
• उस temporary file location को control करने वाले variable के रूप में TEMP चुना गया
• भले ही COMMAND.COM ने TEMP चुना हो, दूसरे programs TEMP या TMP में से क्या इस्तेमाल करेंगे, यह फिर भी उनके अपने implementation पर निर्भर रहा

Windows में TMP को प्राथमिकता मिलने वाला रास्ता बना

• Windows में भी लगभग ऐसा ही विकास हुआ, लेकिन शुरुआती GetTempFileName implementation को इस तरह बनाया गया कि वह TEMP से पहले TMP को जांचे
• जब Windows programs temporary files बनाने के लिए GetTempFileName का उपयोग करते हैं, तो वे TMP को ज्यादा प्राथमिकता देते हैं
• इसलिए “कौन-सा variable सही है?” इसका एक ही जवाब नहीं है; यह इस बात पर निर्भर करता है कि program कौन-सा API या अपना कौन-सा logic इस्तेमाल कर रहा है
• आज भी environment variables settings dialog में TMP और TEMP दोनों मौजूद हैं, और temporary file location के लिए दोनों variables साथ-साथ बने हुए हैं

[GN⁺]

Hacker News टिप्पणियाँ

• दिलचस्प है। यह मेरे दौर से पहले की बात है, इसलिए CP/M प्रोग्रामों को patch करके configure किया जाता था, यह मैंने कभी नहीं सुना था

  • हाँ, यह सच में किया जाता था, और patch code Z80/8080 machine code में होना पड़ता था
    मैंने इसी feature से अपने WordStar के लिए तेज keyboard और screen output routines खुद लिखे थे
  • हाँ, यह सच में था, और जो कुछ प्रोग्राम मूल रूप से CP/M प्रोग्राम थे, वे DOS ke liye WordStar 7.0 तक बहुत लंबे समय तक चले
    मुझे याद है कि WordStar 7 documentation में DOS के debug.exe से program behavior बदलने के लिए इस्तेमाल होने वाली patch locations शामिल थीं
  • आज भी कुछ हद तक यह मौजूद है। suckless के बनाए हुए tools आम तौर पर config.h बदलकर और फिर recompile करके configure किए जाते हैं
    https://suckless.org/
    जोड़ना चाहूँगा कि मैंने बाद में देखा कि इस page के दूसरे subthread में इसका ज़िक्र पहले ही किया जा चुका था
  • उस तरीके की ज़रूरत इसलिए थी क्योंकि RAM और disk space बेहद सीमित थे, और लगभग हर computer के साथ assembler आता था
    बहुत से CP/M प्रोग्रामों को 32K RAM और धीमे 130K floppy, यहाँ तक कि कभी-कभी cassette tape पर भी चलना पड़ता था। 64K RAM और 360K disk होना काफ़ी खास बात थी
    उस समय, आज की तरह नहीं, प्रोग्रामों को market के ऊपरी हिस्से के लिए नहीं बल्कि निचले हिस्से के लिए optimize किया जाता था। जितने ज़्यादा systems पर वे चलते, उतनी ज़्यादा बिक्री होती, और ग्राहकों पर hardware upgrade करने का बोझ नहीं डाला जाता था
    external config files या उन config files को बनाने वाले program के लिए जगह ही नहीं थी, और command-line arguments संभालना भी कीमती bytes खा जाता था
    आजकल लोग शिकायत करते हैं कि MacBook Neo में सिर्फ़ 8,000,000,000 bytes RAM है, लेकिन 1978 में 2,048-byte का basic IDE भी बनाया जा सकता था

• मुझे Raymond का ब्लॉग पसंद है, लेकिन यह कहना अजीब है कि 1973 में microcomputers पर CP/M आम था
  1973 के microcomputers, Intel Intellec जैसे development systems के स्तर के prototype के ज़्यादा क़रीब थे, और उनमें operating system भी नहीं होता था। यह सही है कि Kildall ने CP/M का development 1973 में शुरू किया था, लेकिन उस समय वह केवल PDP-10 mainframe simulator पर चलता था
  1979 हो to baat samajh aati hai, लेकिन 1973 बहुत जल्दी है

  • Wikipedia के अनुसार CP/M 1974 में बनाया गया था, इसलिए यहाँ की timeline निश्चित ही गड़बड़ है
  • यह मज़ेदार है कि 1979 और 1973 के बीच का अंतर, आज के 2020 और वर्तमान के बीच के अंतर के बराबर है
    इस तरह सोचो तो लगता है कि 2020 में ChatGPT था ही नहीं

• यह एक अच्छा उदाहरण है कि शुरुआती developers का लगभग बिना सोचे लिया गया फ़ैसला दशकों तक बना रह सकता है

  • S&P500 product का एक core table, जिस पर मैंने थोड़े समय काम किया था, शायद हमेशा attornies ही कहलाएगा। शुरुआत में किसी ने typo पकड़ा ही नहीं
  • TMPorary decisions जितनी permanent और कोई चीज़ नहीं होती

• प्रोग्रामों ने शायद TMP इसलिए चुना क्योंकि MS-DOS में file extensions अधिकतम 3 अक्षरों के होते थे, और temporary files के लिए .TMP extension इस्तेमाल करने की परंपरा थी

• यह वैसा ही है जैसे Unix प्रोग्रामों में यह एकरूपता नहीं थी कि वे http_proxy देखें या HTTP_PROXY
  आजकल बहुत से प्रोग्राम दोनों देखते हैं, लेकिन जाँचने का क्रम एक जैसा नहीं भी हो सकता है

• CP/M का ज़िक्र उलझाने वाला है। लेखक पहले कहता है कि यह बाद में महत्वपूर्ण होगा, लेकिन अंत में समझाता ऐसा है मानो इसका CP/M या 8080 CPU से कोई संबंध ही नहीं था

  • सहमत हूँ। इस कहानी का CP/M से, और 8080/8086 वाली side-track से भी, बहुत कम लेना-देना है
    असली बात बस यह है कि Microsoft खुद इसका इस्तेमाल करता था, फिर भी इसे standardize करने का इरादा नहीं था
  • अगर CP/M configuration के लिए environment variables इस्तेमाल करता, तो TMP और TEMP में से कौन-सा इस्तेमाल करना है, इसका standard पहले से बन चुका होता और DOS वही मानता
    लेकिन असली रुकावट यह थी कि CP/M में directories नहीं थीं, और DOS 1.0 में भी नहीं थीं
  • क्या आप वह sentence quote कर सकते हैं जिसकी आप बात कर रहे हैं?

• 1995 के आसपास Telstra, यानी Australia Telecom, में पूरे संगठन में लगभग 50,000 desktops थे
  एक दिन सबकी network home directories में null नाम की एक छोटी file दिखाई दी, और लगता है कि किसी Unix user ने .bat file लिखने की कोशिश की थी
  बात वही है कि जब पहले से standard मौजूद ho, तो उसे मानना क्यों ज़रूरी समझा जाए। मैं पूछना चाहता था, “standardize क्यों करें?”, लेकिन लगा कि इससे North America के लोग confuse हो सकते हैं

  • शायद उसने पहले /dev/null आज़माया होगा, वह fail हुआ, तो उसे बस null कर दिया होगा
    नहीं तो यह कहना समझ में नहीं आता कि यह किसी Unix programmer ने किया। बल्कि ज़्यादा संभव है कि किसी DOS programmer ने NUL को ग़लती से null लिख दिया हो
  • मैं जानना चाहूँगा कि वह कौन-सा text था जिसे फेंकने की कोशिश की जा रही थी
  • किसी Logitech driver installer ने भी ऐसा ही कुछ किया था
    उसने hard disk पर NULL नाम की file ढूँढी, और स्वाभाविक है कि .BAT file में > NULL जैसा syntax था

• ईमानदारी से कहूँ तो, कई प्रोग्रामों में home directory में dotfiles बिखेरने की बजाय CP/M-style patch configuration बेहतर लगती है

  • अगर लोग बस XDG Base Directory Specification का पालन करें, तो config files की भरमार समस्या नहीं बनेगी
    Firefox जैसे पुराने रुख़ पर अड़े projects समेत, ज़्यादा से ज़्यादा projects अब इसे अपना रहे हैं
  • suckless की थोड़ी अलग philosophy में से एक यह है कि projects को आम तौर पर source code बदलकर और recompile करके configure किया जाता है
    आधुनिक open source नज़रिए से देखें तो यह मिलता-जुलता approach कहा जा सकता है। हालाँकि इसकी समग्र तपस्वी सोच के कारण ये projects सबको पसंद नहीं आएँगे
  • मूल रूप से सब कुछ .config के अंदर होना चाहिए
    समस्या यह है कि बहुत से app developers सोचते हैं कि उनकी app इतनी खास है कि उसे अलग directory मिलने का हक़ है
  • मुझे central binary registry में इधर-उधर बिखरी settings की तुलना में dotfiles बेहतर लगती हैं, क्योंकि उन्हें grep किया जा सकता है और text editor से manage किया जा सकता है
    हो सकता है यह सिर्फ़ आदत की वजह से हो
  • काश यह standardize हो जाए। अगर कोई distro किसी तरह .config folder को अनिवार्य बना सके, तो मेरे लिए वही विजेता होगा
    हालाँकि शायद अब बहुत देर हो चुकी है

• मुझे नहीं पता था कि यह इतना उलझा हुआ है
  शायद सीख यह है कि हमेशा एक ही path की ओर point कराओ, नहीं तो बड़ी मुसीबत होगी

• Microsoft की ऐसी झुंझलाहट वाली चीज़ों को मैं दशकों से नोट करता आया हूँ
  पहले वहाँ हमेशा कोई न कोई ऐसा “senior developer” होता था जो ऐसे जवाब देता था जैसे उसे सब पता हो। कुछ इस तरह: “temp temporary है और tmp troubleshoot my pc, debug logs के लिए है। इसी वजह से मैं senior हूँ और तुम नहीं”
  जब मैं ख़ुद ज़्यादा senior हुआ, तो समझ आया कि सवाल उठाना सही था, और अब जब मूल Microsoft developers से बात करो तो वे बताते हैं कि यह गलती थी, लेकिन backward compatibility की वजह से बनाए रखा गया
  लेकिन फिर सवाल उठता है कि यह बहाना वैध क्यों है। backward compatibility का हवाला देते हुए भी वे New Outlook जैसी चीज़ों में core compatibility और वास्तविक workflows तोड़ने वाले बदलाव लगातार आगे बढ़ाते रहते हैं। फिर वे निकल लेते हैं, “मैं बुरा developer नहीं हूँ, नए लोगों से पूछो”
  नए लोगों से पूछ भी नहीं सकते, और वे LeetCode hiring barrier के पीछे छिपे रहते हैं। इसलिए यह भी अजीब नहीं कि ऐसी वास्तविक समस्याएँ ठीक नहीं होतीं और New Outlook जैसी चीज़ें निकलती रहती हैं। पहले वाला वही senior developer अब वहीं काम कर रहा है, और असली developers retire हो चुके हैं
  user home की Documents folder को किसी random program द्वारा ग़लत तरीके से इस्तेमाल करने, या OneDrive द्वारा ग़लती से force-delete कर देने जैसी बातों पर Microsoft से भले कोई तर्कसंगत जवाब मिल जाए, लेकिन 6 महीने के भीतर Microsoft कोई random change धकेल देता है जो behavior को और ख़राब दिशा में मोड़ देता है और उस पूरी मूल तर्क-श्रृंखला को तोड़ देता है
  Notepad भी ऐसा ही है। developer interviews में कहा गया था कि जोखिम शून्य होना चाहिए, इसलिए यह बहुत simple program होना चाहिए, लेकिन बाद में इसमें Microsoft account login और Copilot जोड़ दिए गए
  मुझे लगता है LeetCode-style developer attitude और Microsoft culture ने पूरे industry को बिगाड़ दिया है। शांत चर्चा हो ही नहीं पाती, बात जाकर इस पर खत्म होती है कि “तुम Microsoft में काम नहीं करते, इसलिए तुम्हारी बात अमान्य है”
  मुझे Google Chrome का वह मामला बहुत याद है, जब वह admin privileges को bypass करने के लिए AppData में install होता था। उस feature का मूल उद्देश्य साफ़ तौर पर यह नहीं था कि third parties बिना admin privileges के install कर सकें
  लेकिन उस समय Chrome अच्छा था, और लाखों locked-down corporate computers पर third-party exception programs deploy करने का जो chaos था, उसे संभालना पड़ता था, इसलिए developers अब उसे ही intended feature बताकर दोबारा पेश कर रहे हैं