উপস্থাপনা
এই উত্তরের বেশিরভাগ তথ্য ভিস্তার মেশিনে চালিত পরীক্ষার উপর ভিত্তি করে সংগ্রহ করা হয়েছে। অন্যথায় স্পষ্টভাবে বিবরণ না দেওয়া পর্যন্ত, তথ্যটি অন্যান্য উইন্ডোজ সংস্করণগুলিতে প্রযোজ্য কিনা তা আমি নিশ্চিত করিনি।
FINDSTR আউটপুট
ডকুমেন্টেশন FINDSTR এর আউটপুট ব্যাখ্যা করতে কখনই বিরক্ত করে না। এটি মিলিয়ে লাইনগুলি মুদ্রিত হয়েছে এটিকে বোঝায়, তবে এর চেয়ে বেশি কিছুই নয়।
মিলের লাইন আউটপুটটির ফর্ম্যাটটি নিম্নরূপ:
ফাইলের নাম: lineNumber: lineOffset: পাঠ্য
কোথায়
fileName: = ম্যাচিং লাইন থাকা ফাইলটির নাম। যদি অনুরোধটি একটি একক ফাইলের জন্য স্পষ্টভাবে ছিল বা পাইপ ইনপুট বা পুনঃনির্দেশিত ইনপুট অনুসন্ধান করা হয় তবে ফাইলের নাম মুদ্রিত হয় না। মুদ্রিত হলে ফাইলনাম সর্বদা প্রদত্ত যে কোনও পথের তথ্য অন্তর্ভুক্ত করবে। /Sবিকল্পটি ব্যবহারকরা হলে অতিরিক্ত পাথের তথ্য যুক্ত করা হবে। মুদ্রিত পথটি সর্বদা প্রদত্ত পাথের সাথে সম্পর্কিত, বা যদি কোনও সরবরাহ না করা হয় তবে বর্তমান ডিরেক্টরি সম্পর্কিত।
দ্রষ্টব্য - নন-স্ট্যান্ডার্ড (এবং দুর্বল নথিভুক্ত) ওয়াইল্ডকার্ড < এবং ব্যবহার করে একাধিক ফাইল অনুসন্ধান করার সময় ফাইলের নাম উপসর্গ এড়ানো যেতে পারে >। এই ওয়াইল্ডকার্ডগুলি কীভাবে কাজ করে তার সঠিক নিয়মগুলি এখানে পাওয়া যাবে । অবশেষে, আপনি কীভাবে FINDSTR এর সাথে অ-মানক ওয়াইল্ডকার্ডগুলি কাজ করে তার এই উদাহরণটি দেখতে পারেন ।
লাইন নাম্বার : = ইনপুটটির 1 ম লাইন উপস্থাপন করে 1 সহ দশমিক মান হিসাবে উপস্থাপিত মিলের লাইনের লাইন নম্বর। /Nঅপশন নির্দিষ্ট করাথাকলে কেবল মুদ্রিত।
লাইনঅফসেট: = 1 ম লাইনটির 1 ম অক্ষরটি উপস্থাপন করে 0 দিয়ে ম্যাচিং লাইনের সূচনার দশমিক বাইট অফসেট। /Oঅপশন নির্দিষ্ট করাথাকলে কেবল মুদ্রিত। এটিলাইনের মধ্যে ম্যাচের অফসেট নয় । এটি ফাইলের শুরু থেকে শুরু করে লাইনের শুরু পর্যন্ত বাইট সংখ্যা।
পাঠ্য = কোনও <সিআর> এবং / অথবা <এলএফ> সহ মিলের লাইনের বাইনারি উপস্থাপনা। বাইনারি আউটপুট থেকে কিছুই বাদ যায় না, যেমন সমস্ত লাইনের সাথে মেলে এমন উদাহরণটি মূল ফাইলটির সঠিক বাইনারি অনুলিপি তৈরি করবে।
FINDSTR "^" FILE >FILE_COPY
/ এ বিকল্পটি ফাইলনামের রঙ নির্ধারণ করে:, লাইন সংখ্যা:, এবং লাইনঅফসেট: কেবল আউটপুট। ম্যাচিং লাইনের পাঠ্যটি সর্বদা বর্তমান কনসোল রঙের সাথে আউটপুট থাকে। / এ বিকল্পটি তখনই কার্যকর হয় যখন আউটপুট সরাসরি কনসোলে প্রদর্শিত হয়। আউটপুট কোনও ফাইলে পুনঃনির্দেশিত করা বা পাইপ করা হলে / এ বিকল্পের কোনও প্রভাব নেই। আউটপুট CON এ পুনঃনির্দেশিত করা হলে বগি আচরণের বিবরণের জন্য অ্যাকিনির উত্তরে 2018-08-18 সম্পাদনাটি দেখুন ।
এক্সপিতে এক্সপি
ফিনড্রাস্ট্রে বিন্দু হিসাবে প্রদর্শিত বেশিরভাগ নিয়ন্ত্রণের অক্ষর এবং অনেকগুলি বর্ধিত এএসসিআইআই অক্ষর স্ক্রিনে বিন্দু (পিরিয়ড) হিসাবে লাইনগুলি মিলিয়ে বেশিরভাগ প্রিন্টযোগ্য নিয়ন্ত্রণের অক্ষরগুলি প্রদর্শন করে। নিম্নলিখিত নিয়ন্ত্রণের অক্ষরগুলি ব্যতিক্রম; তারা নিজেরাই প্রদর্শন করে: 0x09 ট্যাব, 0x0A লাইনফিড, 0x0B উল্লম্ব ট্যাব, 0x0 সি ফর্ম ফিড, 0x0D ক্যারিজ রিটার্ন।
এক্সপি ফিনড্রাস্ট্র অনেকগুলি বর্ধিত এএসসিআইআই অক্ষর পাশাপাশি বিন্দুতে রূপান্তর করে। এক্সপিতে বিন্দু হিসাবে প্রদর্শিত বর্ধিত ASCII অক্ষরগুলি কমান্ড লাইনে সরবরাহ করার পরে রূপান্তরিত হওয়াগুলির মতোই। দেখুন - "এক্সটেন্ডেড হওয়া ASCII রূপান্তর কমান্ড লাইন প্যারামিটার জন্য ক্যারেক্টার সীমা" অধ্যায়, পরে এই পোস্টে
নিয়ন্ত্রণের অক্ষর এবং প্রসারিত ASCII এক্সপিতে বিন্দুতে রূপান্তরিত হয় না যদি আউটপুটটি পাইপ করা হয়, কোনও ফাইলে পুনঃনির্দেশিত করা হয়, বা একটি ফোর IN () ধারাতে।
ভিস্তা এবং উইন্ডোজ 7 সর্বদা সমস্ত অক্ষরকে নিজের হিসাবে প্রদর্শন করে, বিন্দু হিসাবে কখনও না।
রিটার্ন কোড (ERRORLEVEL)
- 0 (সাফল্য)
- কমপক্ষে একটি ফাইলের কমপক্ষে একটি লাইনে ম্যাচটি পাওয়া গেছে।
- 1 (ব্যর্থতা)
- কোনও ফাইলের কোনও লাইনে কোনও মিল খুঁজে পাওয়া যায় নি।
/A:xxবিকল্প দ্বারা অবৈধ রঙ নির্দিষ্ট
- 2 (ত্রুটি)
- বেমানান বিকল্প
/Lএবং /Rউভয় নির্দিষ্ট
- নিখোঁজ যুক্তি পর
/A:, /F:, /C:, /D:, অথবা/G:
- ফাইল নির্দিষ্ট করেছে
/F:fileবা /G:fileপাওয়া যায় নি
- 255 (ত্রুটি)
অনুসন্ধানের জন্য ডেটা উত্স (উইন্ডোজ with এর সাথে পরীক্ষার ভিত্তিতে আপডেট করা হয়েছে)
ফাইন্ডস্ট্রাস্ট নিম্নলিখিত উত্সগুলির মধ্যে কেবল একটি থেকে ডেটা অনুসন্ধান করতে পারেন:
ফাইলের নামগুলি আর্গুমেন্ট এবং / অথবা /F:fileবিকল্পটি ব্যবহার করে নির্দিষ্ট করা হয়েছে ।
পুনর্নির্দেশের মাধ্যমে স্টিডিন findstr "searchString" <file
একটি পাইপ থেকে তথ্য প্রবাহ type file | findstr "searchString"
যুক্তি / বিকল্পগুলি পুনঃনির্দেশের চেয়ে অগ্রাধিকার নেয়, যা পাইপযুক্ত ডেটার চেয়ে অগ্রাধিকার নেয়।
ফাইলের নাম আর্গুমেন্ট এবং /F:fileএকত্রিত হতে পারে। একাধিক ফাইলের নাম যুক্তি ব্যবহার করা যেতে পারে। যদি একাধিক /F:fileবিকল্প নির্দিষ্ট করা থাকে তবে কেবলমাত্র সর্বশেষটি ব্যবহৃত হয়। ফাইল নাম আর্গুমেন্টে ওয়াইল্ড কার্ডগুলি অনুমোদিত, তবে ফাইলটির মধ্যে নির্দেশিত নয় /F:file।
অনুসন্ধান স্ট্রিং উৎস (উইন্ডোজ 7 পরীক্ষার উপর ভিত্তি করে সংশোধিত) এবং অপশন মিলিত হতে পারে। একাধিক বিকল্প নির্দিষ্ট করা যেতে পারে। যদি একাধিক বিকল্প নির্দিষ্ট করা থাকে তবে কেবলমাত্র সর্বশেষটি ব্যবহৃত হয়। যদি হয় বা ব্যবহৃত হয়, তবে সমস্ত অ-বিকল্প যুক্তি অনুসন্ধানের জন্য ফাইল হিসাবে ধরে নেওয়া হয়। তাহলে তন্ন তন্ন না ব্যবহার করা হয়, তারপর প্রথম অ বিকল্প যুক্তি খোঁজের শব্দগুলির একটি স্থান বিভাজিত তালিকায় হিসাবে গণ্য হবে।
/G:file/C:string/C:string/G:file/G:file/C:string/G:file/C:string
/F:FILEবিকল্পটি ব্যবহার করার সময় ফাইলের মধ্যে ফাইলের নাম অবশ্যই উদ্ধৃত করা উচিত নয় ।
ফাইলের নামগুলিতে স্পেস এবং অন্যান্য বিশেষ অক্ষর থাকতে পারে। বেশিরভাগ কমান্ডের জন্য এই জাতীয় ফাইলের নাম উদ্ধৃত করা দরকার। তবে FINDSTR /F:files.txtবিকল্পটির জন্য ফাইলের মধ্যে ফাইলের নাম প্রয়োজন t txt অবশ্যই উদ্ধৃত করা উচিত নয়। নামটি উদ্ধৃত করা থাকলে ফাইলটি পাওয়া যাবে না।
বাউজি - সংক্ষিপ্ত 8.3 ফাইলের নামগুলি /Dএবং /Sবিকল্পগুলি ভেঙে ফেলতে পারে
সমস্ত উইন্ডোজ কমান্ডের মতো, অনুসন্ধানের জন্য ফাইলগুলি অনুসন্ধান করার জন্য FINDSTR দীর্ঘ নাম এবং সংক্ষিপ্ত 8.3 নাম দুটি মিলিয়ে নেওয়ার চেষ্টা করবে। ধরুন বর্তমান ফোল্ডারে নিম্নলিখিত অ-ফাঁকা ফাইল রয়েছে:
b1.txt
b.txt2
c.txt
নিম্নলিখিত কমান্ডটি সফলভাবে সমস্ত 3 ফাইল সন্ধান করবে:
findstr /m "^" *.txt
b.txt2মিল আছে কারণ সম্পর্কিত সংক্ষিপ্ত নামের সাথে B9F64~1.TXTমেলে। এটি অন্যান্য সমস্ত উইন্ডোজ কমান্ডের আচরণের সাথে সামঞ্জস্যপূর্ণ।
তবে /Dএবং /Sঅপশন সহ একটি বাগের ফলে নিম্নলিখিত কমান্ডগুলি কেবল সন্ধান করতে পারেb1.txt
findstr /m /d:. "^" *.txt
findstr /m /s "^" *.txt
বাগটি b.txt2খুঁজে পাওয়া থেকে বাধা দেয় এবং b.txt2সেই সাথে একই ডিরেক্টরি অনুসারে বাছাই করা সমস্ত ফাইলের নাম । এর আগে বাছাইকৃত অতিরিক্ত ফাইলগুলি a.txtপাওয়া যায়। d.txtত্রুটি শুরু হওয়ার পরে যেমন অতিরিক্ত ফাইলগুলি পরে সাজানো হয়, তেমনি মিস হয়।
অনুসন্ধান প্রতিটি ডিরেক্টরি স্বাধীনভাবে চিকিত্সা করা হয়। উদাহরণস্বরূপ, /Sবিকল্পটি পিতামাতার মধ্যে ফাইলগুলি সন্ধান করতে ব্যর্থ হওয়ার পরে চাইল্ড ফোল্ডারে সাফল্যের সাথে অনুসন্ধান শুরু করবে, তবে বাগটি বাচ্চার মধ্যে একটি ছোট ফাইলের নামটি মিস করার পরে, সেই শিশু ফোল্ডারের পরবর্তী সমস্ত ফাইলও বাদ দেওয়া হবে ।
এনটিএফএস 8.3 নাম জেনারেশন অক্ষম করে এমন কোনও মেশিনে যদি একই ফাইলের নাম তৈরি করা হয় তবে কমান্ডগুলি বাগ ফ্রি কাজ করে। অবশ্যই b.txt2পাওয়া যাবে না, তবে c.txtসঠিকভাবে পাওয়া যাবে।
সমস্ত সংক্ষিপ্ত নাম বাগটি ট্রিগার করে না। বগড আচরণের সমস্ত দৃষ্টান্ত আমি দেখেছি এমন একটি এক্সটেনশন জড়িত যা সংক্ষিপ্ত 8.3 নাম সহ 3 টি অক্ষরের চেয়ে দীর্ঘ হয় যা একটি সাধারণ নাম হিসাবে শুরু হয় যার জন্য 8.3 নাম প্রয়োজন হয় না।
এক্সপি, ভিস্তা এবং উইন্ডোজ 7 এ বাগটি নিশ্চিত হয়ে গেছে।
মুদ্রণযোগ্য নয় এমন অক্ষর এবং /Pবিকল্প বিকল্প FINDSTR নিম্নলিখিত দশমিক বাইট কোডের কোন ধারণ করে যেকোনো ফাইল এড়িয়ে যেতে কারণ:
0-7, 14-25, 27-31।
/P
অন্য একটি উপায় রাখুন, /Pবিকল্পটি কেবল এমন ফাইলগুলিকে এড়িয়ে যাবে যা মুদ্রণযোগ্য নিয়ন্ত্রণের অক্ষরগুলি ধারণ করে। নিয়ন্ত্রণের অক্ষরগুলি 31 (0x1F) এর চেয়ে কম বা সমান কোড equal FINDSTR নিম্নলিখিত নিয়ন্ত্রণ অক্ষরগুলি মুদ্রণযোগ্য হিসাবে গণ্য করে:
8 0x08 backspace
9 0x09 horizontal tab
10 0x0A line feed
11 0x0B vertical tab
12 0x0C form feed
13 0x0D carriage return
26 0x1A substitute (end of text)
অন্যান্য সমস্ত কন্ট্রোল ক্যারেক্টারকে প্রিন্টযোগ্য হিসাবে বিবেচনা করা হয়, যার উপস্থিতি /Pফাইলটি এড়িয়ে যাওয়ার বিকল্পের কারণ হয়ে থাকে।
পাইপযুক্ত এবং পুনঃনির্দেশিত ইনপুট <CR><LF>সংযুক্ত থাকতে পারে
যদি ইনপুটটি পাইপ করা হয় এবং স্ট্রিমের শেষ অক্ষরটি না থাকে <LF>তবে FINDSTR স্বয়ংক্রিয়ভাবে ইনপুটটিতে সংযোজন হবে <CR><LF>। এটি এক্সপি, ভিস্তা এবং উইন্ডোজ on এ নিশ্চিত হয়ে গেছে (আমি মনে করতাম যে উইন্ডোজ পাইপটি ইনপুটটি সংশোধন করার জন্য দায়ী ছিল তবে আমি তখন থেকেই আবিষ্কার করেছি যে প্রকৃতপক্ষে এফআইএনডিআরএসটি সংশোধন করছে।)
একইভাবে ভিস্তার উপর পুনর্নির্দেশিত ইনপুটটির ক্ষেত্রেও সত্য। পুনর্নির্দেশিত ইনপুট হিসাবে ব্যবহৃত কোনও ফাইলের শেষ চরিত্রটি যদি না হয় <LF>তবে FINDSTR স্বয়ংক্রিয়ভাবে ইনপুটটিতে যুক্ত হবে <CR><LF>। তবে এক্সপি এবং উইন্ডোজ 7 পুনঃনির্দেশিত ইনপুটটিকে পরিবর্তন করে না।
এক্সপ্লোর পরিচালনা উইন্ডোতে পুনর্নির্দেশিত ইনপুটটি শেষ না হলে এক্সপ্লোর পরিচালনা উইন্ডোজ এক্সপি এবং উইন্ডোজ<LF>
on এ <LF>স্থগিত হয় X পুনঃনির্দেশিত ফাইলের শেষে পৌঁছে যায়।
পাইপড ডেটার শেষ লাইনটি যদি একটি একক অক্ষর নিয়ে থাকে তবে তা উপেক্ষা করা যেতে পারে যদি ইনপুটটি পাইপ করা হয় এবং শেষ লাইনে একটি একক অক্ষর থাকে যা অনুসরণ করে না <LF>, তবে FINDSTR সম্পূর্ণ লাইনটি উপেক্ষা করে ign
উদাহরণ - একক অক্ষর সহ প্রথম কমান্ড <LF>মিলতে ব্যর্থ হয় তবে ২ টি অক্ষর সহ দ্বিতীয় কমান্ড ঠিকঠাকভাবে কাজ করে, তৃতীয় কমান্ড যেমন একটি নতুন অক্ষর সমাপ্ত করে একটি অক্ষর রাখে।
> set /p "=x" <nul | findstr "^"
> set /p "=xx" <nul | findstr "^"
xx
> echo x| findstr "^"
x
নতুন ফাইস্টস্ট্র বাগটিতে ডসটিপস ব্যবহারকারী স্পঞ্জ বেলি রিপোর্ট করেছেন । এক্সপি, উইন্ডোজ 7 এবং উইন্ডোজ 8 এ নিশ্চিত হয়েছে V এখনও ভিস্তার সম্পর্কে শোনেনি। (পরীক্ষার জন্য আমার আর ভিস্তা নেই)।
অপশন সিনট্যাক্স
বিকল্পগুলির সাথে উভয়ই উপসর্গ করা
যেতে পারে /বা -বিকল্পগুলি একক পরে /বা পরে একত্রিত হতে পারে -। তবে সংক্ষিপ্ত বিকল্প তালিকায় সর্বাধিক একটি মাল্টিচার্যাক্টর বিকল্প থাকতে পারে যেমন অফ বা এফ:, এবং মাল্টি-চরিত্রের বিকল্পটি তালিকার সর্বশেষ বিকল্প হতে হবে।
"হ্যালো" এবং "বিদায়" উভয় ক্রমে যে কোনও রেখার জন্য কেস সংবেদনশীল রেজেক্স অনুসন্ধানের প্রকাশের সমস্ত সমমানের উপায় নীচে রয়েছে
/i /r /c:"hello.*goodbye" /c:"goodbye.*hello"
-i -r -c:"hello.*goodbye" /c:"goodbye.*hello"
/irc:"hello.*goodbye" /c:"goodbye.*hello"
অনুসন্ধানের স্ট্রিংয়ের দৈর্ঘ্য সীমা ভিস্টায় একক অনুসন্ধান স্ট্রিংয়ের সর্বাধিক অনুমোদিত দৈর্ঘ্য 511 বাইট। যদি কোনও অনুসন্ধানের স্ট্রিং 511 ছাড়িয়ে যায় তবে ফলাফলটি FINDSTR: Search string too long.ERRORLEVEL 2 এর সাথে একটি ত্রুটি।
নিয়মিত অভিব্যক্তি অনুসন্ধান করার সময় সর্বাধিক সন্ধানের স্ট্রিংয়ের দৈর্ঘ্য 254 25 255 এবং 511 এর দৈর্ঘ্য সহ একটি নিয়মিত অভিব্যক্তি FINDSTR: Out of memoryERRORLEVEL 2 এর সাথে ত্রুটি ঘটবে A একটি নিয়মিত প্রকাশের দৈর্ঘ্য> 511 FINDSTR: Search string too long.ত্রুটির ফলস্বরূপ ।
উইন্ডোজ এক্সপিতে অনুসন্ধানের স্ট্রিংয়ের দৈর্ঘ্য স্পষ্টতই কম। ফাইন্ডস্ট্রার ত্রুটি: "অনুসন্ধানের স্ট্রিং খুব দীর্ঘ": কীভাবে "লুপ" এর মধ্যে স্ট্রিংগুলি নিষ্কাশন করতে এবং মেলে?
আক্ষরিক এবং রেজেক্স উভয় অনুসন্ধানের জন্য এক্সপি সীমা 127 বাইট।
লাইন দৈর্ঘ্য সীমা
কমান্ড লাইন আর্গুমেন্ট হিসাবে বা / এফ: ফাইল ফাইলের মাধ্যমে নির্দিষ্ট করা ফাইলগুলির কোনও লাইন দৈর্ঘ্যের সীমা নেই। অনুসন্ধানগুলি 128MB ফাইলের বিরুদ্ধে সফলভাবে পরিচালিত হয়েছিল যাতে একটি << এলএফ> নেই।
পাইপযুক্ত ডেটা এবং পুনঃনির্দেশিত ইনপুট প্রতি লাইন 8191 বাইটের মধ্যে সীমাবদ্ধ। এই সীমাটি FINDSTR এর একটি "বৈশিষ্ট্য"। এটি পাইপ বা পুনঃনির্দেশের সহজাত নয়। পুনর্নির্দেশিত স্টিডিন বা পাইপযুক্ত ইনপুট ব্যবহার করে FINDSTR>> = 8 কে বাইটের কোনও লাইনের সাথে মেলে না। লাইন> = 8 কে স্টাডারে একটি ত্রুটি বার্তা উত্পন্ন করে, তবে অনুসন্ধান স্ট্রিংটি কমপক্ষে একটি ফাইলের কমপক্ষে একটি লাইনে সন্ধান পেলে ERRORLEVEL এখনও 0 হয়।
ডিফল্ট অনুসন্ধানের: আক্ষরিক বনাম নিয়মিত এক্সপ্রেশন
/C:"string" - ডিফল্টটি হল / এল আক্ষরিক। স্পষ্টভাবে / সি বিকল্পের সাথে / সি মিশ্রন করা: "স্ট্রিং" অবশ্যই কাজ করে তবে অনর্থক।
"string argument"- ডিফল্ট খুব প্রথম অনুসন্ধানের স্ট্রিংয়ের সামগ্রীর উপর নির্ভর করে। (মনে রাখবেন যে <স্পেস> সন্ধানের স্ট্রিংগুলি সীমিত করতে ব্যবহৃত হয়)) যদি প্রথম অনুসন্ধান স্ট্রিংটি একটি বৈধ নিয়মিত অভিব্যক্তি হয় যা অন্তত একটি অব্যাহত মেটা-অক্ষর ধারণ করে, তবে সমস্ত অনুসন্ধানের স্ট্রিংগুলিকে নিয়মিত এক্সপ্রেশন হিসাবে বিবেচনা করা হবে। অন্যথায় সমস্ত অনুসন্ধানের স্ট্রিংগুলিকে আক্ষরিক হিসাবে বিবেচনা করা হয়। উদাহরণস্বরূপ, "51.4 200"দুটি নিয়মিত এক্সপ্রেশন হিসাবে বিবেচিত হবে কারণ প্রথম স্ট্রিংটিতে একটি অব্যক্ত ডট রয়েছে, যেখানে "200 51.4"দুটি আক্ষরিক হিসাবে বিবেচিত হবে কারণ প্রথম স্ট্রিংয়ে কোনও মেটা-অক্ষর নেই।
/G:file- ডিফল্ট ফাইলের প্রথম খালি খালি লাইনের সামগ্রীর উপর নির্ভর করে। যদি প্রথম অনুসন্ধানের স্ট্রিংটি একটি বৈধ নিয়মিত অভিব্যক্তি হয় যা অন্তত একটি অব্যাহত মেটা-চরিত্র ধারণ করে, তবে সমস্ত অনুসন্ধানের স্ট্রিংগুলিকে নিয়মিত এক্সপ্রেশন হিসাবে বিবেচনা করা হবে। অন্যথায় সমস্ত অনুসন্ধানের স্ট্রিংগুলিকে আক্ষরিক হিসাবে বিবেচনা করা হয়।
সুপারিশ - সর্বদা স্পষ্টভাবে উল্লেখ /Lআক্ষরিক বিকল্প বা /Rযখন ব্যবহার রেগুলার এক্সপ্রেশন বিকল্প "string argument"বা /G:file।
বাউজি - একাধিক আক্ষরিক অনুসন্ধানের স্ট্রিং নির্দিষ্ট করা অবিশ্বাস্য ফলাফল দিতে পারে
নিম্নলিখিত সাধারণ FINDSTR উদাহরণটি মিল থাকা সত্ত্বেও কোনও মিল খুঁজে পেতে ব্যর্থ।
echo ffffaaa|findstr /l "ffffaaa faffaffddd"
এই বাগটি উইন্ডোজ সার্ভার 2003, উইন্ডোজ এক্সপি, ভিস্তা এবং উইন্ডোজ 7 এ নিশ্চিত করা হয়েছে।
পরীক্ষার উপর ভিত্তি করে, নিম্নলিখিত সমস্ত শর্ত পূরণ হলে FINDSTR ব্যর্থ হতে পারে:
- অনুসন্ধানটি একাধিক আক্ষরিক অনুসন্ধানের স্ট্রিং ব্যবহার করছে
- অনুসন্ধানের স্ট্রিংগুলি বিভিন্ন দৈর্ঘ্যের
- একটি সংক্ষিপ্ত অনুসন্ধান স্ট্রিংটিতে দীর্ঘতর অনুসন্ধানের স্ট্রিং সহ কিছু পরিমাণ ওভারল্যাপ রয়েছে
- অনুসন্ধান কেস সংবেদনশীল (কোনও
/Iবিকল্প নেই)
প্রতিটি ব্যর্থতার মধ্যে আমি দেখেছি, এটি সর্বদা সংক্ষিপ্ত অনুসন্ধান স্ট্রিংগুলির মধ্যে একটি যা ব্যর্থ হয়।
আরও তথ্যের জন্য দেখুন কেন একাধিক আক্ষরিক অনুসন্ধানের স্ট্রিং সহ এই FINDSTR উদাহরণটি কোনও মিল খুঁজে পাচ্ছে না?
কমান্ড লাইনের আর্গুমেন্টের মধ্যে উদ্ধৃতি এবং ব্যাকস্ল্যাসগুলি
দ্রষ্টব্য - ব্যবহারকারী এমসির এনডির মন্তব্যগুলি এই বিভাগের জন্য প্রকৃত ভয়াবহ জটিল নিয়মগুলি প্রতিফলিত করে। জড়িত রয়েছে 3 স্বতন্ত্র পার্সিং পর্যায়ক্রমে:
- প্রথম সেমিডি.এক্স.কে কিছু উদ্ধৃতি ^ "হিসাবে পালাতে হতে পারে (প্রকৃতপক্ষে FINDSTR এর সাথে কিছুই করার নেই)
- পরবর্তী FINDSTR ২০০৮- এর পূর্বের এমএস সি / সি ++ আর্গুমেন্ট পার্সার ব্যবহার করে, এতে "এবং for
- আর্গুমেন্ট পার্সার শেষ হওয়ার পরে, FINDSTR অতিরিক্তভাবে আচরণ করে \ তারপরে একটি আলফা-সংখ্যাসূচক অক্ষরকে আক্ষরিক হিসাবে চিহ্নিত করে, তবে escape ন্যূন-আলফা-সংখ্যাসূচক চরিত্রটিকে একটি পালানোর চরিত্র হিসাবে অনুসরণ করে
এই হাইলাইট করা অংশটির অবশিষ্টাংশ 100% সঠিক নয়। এটি অনেক পরিস্থিতিতে গাইড হিসাবে কাজ করতে পারে তবে সম্পূর্ণ বোঝার জন্য উপরের নিয়মগুলি প্রয়োজন।
কমান্ড লাইনের সন্ধানের স্ট্রিংয়ের মধ্যে রেকর্ডিং কোট কমান্ড লাইনের সন্ধানের স্ট্রিংয়ের
মধ্যে উদ্ধৃতি অবশ্যই ব্যাকস্ল্যাশের মতো এড়াতে হবে
\"। এটি আক্ষরিক এবং রেজেক্স অনুসন্ধান উভয় স্ট্রিংয়ের ক্ষেত্রেই সত্য। এক্সপি, ভিস্তা এবং উইন্ডোজ 7 এ এই তথ্যটি নিশ্চিত করা হয়েছে।
দ্রষ্টব্য: সিএমডি.এক্সইএস পার্সারটির জন্য উদ্ধৃতিটি এড়ানো দরকার হতে পারে, তবে এটির সাথে ফিনড্রাস্ট্রের কোনও সম্পর্ক নেই। উদাহরণস্বরূপ, একক উদ্ধৃতি অনুসন্ধান করতে আপনি ব্যবহার করতে পারেন:
FINDSTR \^" file && echo found || echo not found
আক্ষরিক অনুসন্ধানের স্ট্রিংয়ের মধ্যে কমান্ড লাইনের আক্ষরিক অনুসন্ধানের স্ট্রিংগুলির মধ্যে
ব্যাকস্ল্যাশ থেকে বেরিয়ে আসা সাধারণত \বা হিসাবে হিসাবে প্রতিনিধিত্ব করা যেতে পারে
\\। তারা সাধারণত সমতুল্য। (ভিস্টায় এমন অস্বাভাবিক ঘটনা ঘটতে পারে যেখানে ব্যাকস্ল্যাশ সবসময় এড়ানো উচিত, তবে আমার কাছে পরীক্ষার জন্য ভিস্তার মেশিন আর নেই) ।
তবে কয়েকটি বিশেষ মামলা রয়েছে:
পরপর ব্যাকস্ল্যাশগুলি অনুসন্ধান করার সময়, শেষ ব্যতীত সমস্তগুলি অবশ্যই পালাতে হবে। শেষ ব্যাকস্ল্যাশ optionচ্ছিকভাবে পালাতে পারে।
\\যেমন কোডেড করা যেতে পারে \\\বা\\\\\\\যেমন কোডেড করা যেতে পারে \\\\\বা\\\\\\
উদ্ধৃতিটি উদ্ভট হওয়ার আগে এক বা একাধিক ব্যাকস্ল্যাশ অনুসন্ধান করা। লজিক পরামর্শ দিবে যে উদ্ধৃতিটি অবশ্যই পালাতে হবে, এবং নেতৃস্থানীয় ব্যাকস্ল্যাশগুলির প্রত্যেককে পালাতে হবে, তবে এটি কার্যকর হয় না! পরিবর্তে, নেতৃস্থানীয় ব্যাকস্ল্যাশগুলির প্রত্যেককে অবশ্যই ডাবল পলায়ন করতে হবে, এবং উদ্ধৃতিটি সাধারণত চালিয়ে যেতে হবে:
\" হিসাবে কোড করা আবশ্যক \\\\\"\\" হিসাবে কোড করা আবশ্যক \\\\\\\\\"
পূর্বে উল্লিখিত হিসাবে, এক বা একাধিক অব্যাহতিপ্রাপ্ত উদ্ধৃতিগুলির ^জন্য সিএমডি পার্সারটি সহ পালানোর প্রয়োজন হতে পারে
এই বিভাগের তথ্যটি এক্সপি এবং উইন্ডোজ 7 এ নিশ্চিত করা হয়েছে।
কমান্ড লাইন রেজেক্স অনুসন্ধানের স্ট্রিংয়ের মধ্যে ব্যাকস্ল্যাশ ছেড়ে যাওয়া
শুধুমাত্র ভিস্তা: একটি রেজেজে ব্যাকস্ল্যাশ অবশ্যই ডাবল পলায়নের মতো হতে হবে \\\\, না হলে অন্যরকম অক্ষর শ্রেণির মধ্যে একক পালাতে হবে
[\\]
এক্সপি এবং উইন্ডোজ 7: একটি রেগেক্সে ব্যাকস্ল্যাশ সর্বদা হিসাবে প্রতিনিধিত্ব করা যেতে পারে [\\]। এটি সাধারণত হিসাবে প্রতিনিধিত্ব করা যেতে পারে \\। তবে ব্যাকস্ল্যাশটি যদি একটি পালিয়ে থাকা উদ্ধৃতিটির আগে থাকে তবে এটি কখনই কার্যকর হয় না।
একটি পালানো উদ্ধৃতি দেওয়ার আগে এক বা একাধিক ব্যাকস্ল্যাশগুলি হয় দ্বিগুণ পালাতে হবে, অন্যথায় কোড করা উচিত [\\]
\"যেমন কোডেড করা হতে পারে \\\\\"বা[\\]\"\\"যেমন কোডেড করা হতে পারে \\\\\\\\\"বা [\\][\\]\"বা\\[\\]\"
/ জি-র মধ্যে
কোট এবং ব্যাকস্ল্যাশ ছেড়ে যাওয়া: ফাইলের আক্ষরিক অনুসন্ধানের স্ট্রিং / জি দ্বারা নির্দিষ্ট আক্ষরিক অনুসন্ধান স্ট্রিং ফাইলের মধ্যে স্ট্যান্ডেলোন কোটস এবং ব্যাকস্ল্যাশগুলি এড়ানোর দরকার হয় না, তবে তারা হতে পারে।
"এবং \"সমতুল্য।
\এবং \\সমতুল্য।
যদি উদ্দেশ্যটি \\ সন্ধান করতে হয় তবে কমপক্ষে নেতৃস্থানীয় ব্যাকস্ল্যাশ এড়াতে হবে। উভয় \\\এবং \\\\কাজ।
যদি উদ্দেশ্যটি find "অনুসন্ধান করা হয়, তবে কমপক্ষে নেতৃস্থানীয় ব্যাকস্ল্যাশ এড়াতে হবে। \\"এবং উভয়ই \\\"কাজ করুন।
/ জি-এর মধ্যেই উদ্ধৃতি এবং ব্যাকস্ল্যাশ ছেড়ে যাওয়া: ফাইলের রেজেক্স অনুসন্ধানের স্ট্রিং
এটি এমন এক ক্ষেত্রে যেখানে ডকুমেন্টের ভিত্তিতে অব্যাহতি সিক্যুয়েন্সগুলি প্রত্যাশা অনুযায়ী কাজ করে। উদ্ধৃতিটি কোনও রেজেক্স মেটাচার্যাক্টর নয়, সুতরাং এড়াতে হবে না (তবে হতে পারে)। ব্যাকস্ল্যাশ হ'ল একটি রেজেক্স মেটাচার্যাক্টর, সুতরাং এটি এড়াতে হবে।
কমান্ড লাইন প্যারামিটারগুলির জন্য অক্ষরের সীমা - প্রসারিত ASCII রূপান্তর
নাল অক্ষর (0x00) কমান্ড লাইনের কোনও স্ট্রিংয়ে উপস্থিত হতে পারে না। অন্য কোনও একক বাইট অক্ষর স্ট্রিং (0x01 - 0xFF) এ উপস্থিত হতে পারে। তবে, FINDSTR কমান্ড লাইন প্যারামিটারের মধ্যে পাওয়া অনেকগুলি বর্ধিত ASCII অক্ষরকে অন্য অক্ষরে রূপান্তর করে। এটি দুটি উপায়ে একটি বড় প্রভাব ফেলে:
1) কমান্ড লাইনে অনুসন্ধানের স্ট্রিং হিসাবে ব্যবহৃত হলে অনেকগুলি বর্ধিত ASCII অক্ষর তাদের সাথে মেলে না। আক্ষরিক এবং রেজেক্স অনুসন্ধানগুলির জন্য এই সীমাবদ্ধতা একই। যদি কোনও অনুসন্ধানের স্ট্রিংয়ে অবশ্যই বর্ধিত ASCII থাকতে পারে তবে তার /G:FILEপরিবর্তে বিকল্পটি ব্যবহার করা উচিত।
2) নামটি প্রসারিত ASCII অক্ষর রয়েছে এবং ফাইলটির নাম কমান্ড লাইনে নির্দিষ্ট করা থাকলে ফাইল খুঁজে পেতে ব্যর্থ হতে পারে I যদি অনুসন্ধান করা কোনও ফাইলের নামে প্রসারিত ASCII থাকে, তবে /F:FILEপরিবর্তে বিকল্পটি ব্যবহার করা উচিত।
এফআইএনডিআরএসটি কমান্ড লাইন স্ট্রিংগুলিতে সম্পাদিত সম্প্রসারিত ASCII অক্ষর রূপান্তরগুলির একটি সম্পূর্ণ তালিকা এখানে রয়েছে। প্রতিটি অক্ষর দশমিক বাইট কোড মান হিসাবে প্রতিনিধিত্ব করা হয়। প্রথম কোডটি কমান্ড লাইনে সরবরাহিত অক্ষরকে উপস্থাপন করে এবং দ্বিতীয় কোডটি রূপান্তরিত চরিত্রটিকে উপস্থাপন করে। দ্রষ্টব্য - এই তালিকাটি মার্কিন মেশিনে সংকলিত হয়েছিল। অন্যান্য ভাষার এই তালিকাতে কী প্রভাব ফেলতে পারে তা আমি জানি না।
158 treated as 080 199 treated as 221 226 treated as 071
169 treated as 170 200 treated as 043 227 treated as 112
176 treated as 221 201 treated as 043 228 treated as 083
177 treated as 221 202 treated as 045 229 treated as 115
178 treated as 221 203 treated as 045 231 treated as 116
179 treated as 221 204 treated as 221 232 treated as 070
180 treated as 221 205 treated as 045 233 treated as 084
181 treated as 221 206 treated as 043 234 treated as 079
182 treated as 221 207 treated as 045 235 treated as 100
183 treated as 043 208 treated as 045 236 treated as 056
184 treated as 043 209 treated as 045 237 treated as 102
185 treated as 221 210 treated as 045 238 treated as 101
186 treated as 221 211 treated as 043 239 treated as 110
187 treated as 043 212 treated as 043 240 treated as 061
188 treated as 043 213 treated as 043 242 treated as 061
189 treated as 043 214 treated as 043 243 treated as 061
190 treated as 043 215 treated as 043 244 treated as 040
191 treated as 043 216 treated as 043 245 treated as 041
192 treated as 043 217 treated as 043 247 treated as 126
193 treated as 045 218 treated as 043 249 treated as 250
194 treated as 045 219 treated as 221 251 treated as 118
195 treated as 043 220 treated as 095 252 treated as 110
196 treated as 045 222 treated as 221 254 treated as 221
197 treated as 043 223 treated as 095
198 treated as 221 224 treated as 097
উপরের তালিকায় নেই এমন কোনও চরিত্র> 0 <CR>এবং নিজের সাথে </ i> সহ হিসাবে বিবেচিত হবে LF>। বিজোড় চরিত্রগুলিকে পছন্দ করার মতো <CR>এবং অন্তর্ভুক্ত করার সহজ উপায় <LF>হ'ল এটিকে পরিবেশের পরিবর্তনশীল করে তোলা এবং কমান্ড লাইন আর্গুমেন্টের মধ্যে বিলম্বিত সম্প্রসারণ ব্যবহার করা।
/ জি: ফাইল এবং / এফ দ্বারা নির্দিষ্ট ফাইলগুলিতে স্ট্রিংগুলির জন্য অক্ষরের সীমা: ফাইল ফাইলগুলি
নুল (0x00) অক্ষরটি ফাইলটিতে উপস্থিত হতে পারে তবে এটি সি স্ট্রিং টার্মিনেটরের মতো কাজ করে। নুল চরিত্রের পরে যে কোনও অক্ষরকে আলাদা স্ট্রিং হিসাবে বিবেচনা করা হয় যেন তারা অন্য লাইনে রয়েছে।
<CR>এবং <LF>অক্ষর লাইন terminators যে একটি স্ট্রিং বিনষ্ট, এবং স্ট্রিং অন্তর্ভুক্ত করা হয় না যেমন চিকিত্সা করা হয়।
অন্যান্য সমস্ত একক বাইট অক্ষর একটি স্ট্রিং মধ্যে নিখুঁত অন্তর্ভুক্ত করা হয়।
ইউনিকোড ফাইলগুলি অনুসন্ধান করা
FINDSTR সঠিকভাবে সর্বাধিক ইউনিকোড (ইউটিএফ -16, ইউটিএফ-16 এলই, ইউটিএফ-16 বিই, ইউটিএফ -32) অনুসন্ধান করতে পারে না কারণ এটি নুল বাইটগুলি অনুসন্ধান করতে পারে না এবং ইউনিকোডে সাধারণত অনেকগুলি নুল বাইট থাকে।
তবে, টিওয়াইপি কমান্ডটি ইউটিএফ -১LE এলএকে বিওএম-এর সাথে একক বাইট অক্ষর সংকেতে রূপান্তরিত করে, সুতরাং নীচের মতো একটি কমান্ড বিওএমের সাথে ইউটিএফ -১ 16 এলএ নিয়ে কাজ করবে।
type unicode.txt|findstr "search"
নোট করুন যে ইউনিকোড কোড পয়েন্টগুলি আপনার সক্রিয় কোড পৃষ্ঠা দ্বারা সমর্থিত নয় তা ?অক্ষরে রূপান্তরিত হবে ।
ইউটিএফ -8 অনুসন্ধান করা সম্ভব যতক্ষণ না আপনার অনুসন্ধানের স্ট্রিংয়ে কেবলমাত্র এএসসিআইআই রয়েছে। তবে, কোনও মাল্টি-বাইট UTF-8 টি অক্ষরের কনসোল আউটপুট সঠিক হবে না। আপনি যদি আউটপুটটিকে কোনও ফাইলে পুনর্নির্দেশ করেন তবে ফলাফলটি সঠিকভাবে এনকোডেড ইউটিএফ -8 হবে। মনে রাখবেন যে যদি ইউটিএফ -8 ফাইলটিতে একটি বিওএম থাকে, তবে বিওএমটিকে প্রথম লাইনের অংশ হিসাবে বিবেচনা করা হবে, যা কোনও লাইনের শুরুর সাথে মিলে এমন কোনও অনুসন্ধান ফেলে দিতে পারে।
আপনি যদি নিজের অনুসন্ধান স্ট্রিংটি কোনও ইউটিএফ -8 এনকোডেড অনুসন্ধান ফাইলে রাখেন (বিওএম ছাড়াই) এবং / জি বিকল্পটি ব্যবহার করেন তবে মাল্টি-বাইট ইউটিএফ -8 অক্ষর অনুসন্ধান করা সম্ভব।
লাইনের
শেষের শেষে FINDSTR প্রতি <LF> এর পরপরই লাইনগুলি বিভক্ত করে। <CR> এর উপস্থিতি বা অনুপস্থিতির লাইন ব্রেকগুলিতে কোনও প্রভাব নেই।
লাইন বিরতিগুলি জুড়ে অনুসন্ধান করা
প্রত্যাশা অনুযায়ী, .রেজেক্স মেটাক্রেটার <CR> বা <LF> এর সাথে মেলে না। কমান্ড লাইন অনুসন্ধানের স্ট্রিংটি ব্যবহার করে একটি লাইন বিরতিতে অনুসন্ধান করা সম্ভব। <CR> এবং <LF> অক্ষর দুটিই সুস্পষ্টভাবে মিলে যেতে হবে। যদি কোনও বহু-লাইন মিল পাওয়া যায়, তবে ম্যাচের প্রথম লাইনটিই মুদ্রিত হয়। FINDSTR এর পরে উত্সের দ্বিতীয় লাইনে দ্বিগুণ হয়ে আবার অনুসন্ধান শুরু করে - "সামনের দিকে তাকান" প্রকারের বৈশিষ্ট্যটি সাজান।
অনুমান করুন পাঠ্য। টিএক্সটি-তে এই বিষয়গুলি রয়েছে (ইউনিক্স বা উইন্ডোজ স্টাইল হতে পারে)
A
A
A
B
A
A
তারপরে এই স্ক্রিপ্টটি
@echo off
setlocal
::Define LF variable containing a linefeed (0x0A)
set LF=^
::Above 2 blank lines are critical - do not remove
::Define CR variable containing a carriage return (0x0D)
for /f %%a in ('copy /Z "%~dpf0" nul') do set "CR=%%a"
setlocal enableDelayedExpansion
::regex "!CR!*!LF!" will match both Unix and Windows style End-Of-Line
findstr /n /r /c:"A!CR!*!LF!A" TEST.TXT
এই ফলাফল দেয়
1:A
2:A
5:A
লাইন বিরতিগুলি জুড়ে / জি: ফাইল ব্যবহার করে অনুসন্ধানটি অপ্রচলিত কারণ <CRCR বা <LF> এর সাথে মিলানোর একমাত্র উপায় হ'ল ইওএল অক্ষরগুলিকে স্যান্ডউইচ করে এমন একটি রেইগেক্স অক্ষর শ্রেণির পরিসীমা এক্সপ্রেশন via
[<TAB>-<0x0B>] <LF> এর সাথে মেলে তবে এটি <TAB> এবং <0x0B> এর সাথেও মেলে
[<0x0C>-!] <CR> মেলে তবে এটি <0x0C> এবং এর সাথেও মেলে!
দ্রষ্টব্য - উপরেরগুলি রেজেক্স বাইট স্ট্রিমের প্রতীকী উপস্থাপনা কারণ আমি গ্রাফিকালি অক্ষরগুলি উপস্থাপন করতে পারি না।
উত্তর নীচের অংশ 2 অবিরত ...
grepযা হয় খুব ভাল বোঝা যায় এবং নথিভুক্ত :-) দেখুন stackoverflow.com/questions/2635740/... উদাহরণস্বরূপ।