I am trying to send the content of a text file (which is just one word) into a variable in MS-DOS.
I tried doing it with pipes like so ,without any success
TYPE username.txt | %savedName%
Can anyone enlighten me?
for /f "delims=" %%i in (username.txt) do set "savedname=%%i"
echo savedname=%savedname%
should work for you (as a batch file). If you are executing directly from the prompt, then reduce each %% to %.
If you are nunning this on a Windows machine using WIN NT4, Win2000, WINXP, WIN7, Vista or Win8 then this should work (as also the set/p approach should have worked)
If you are using Win95, Win98, WinME or real MSDOS, then a different approach would be required.
"MSDOS" is often used to mean "Command Prompt" - a generic term ridiculously misapplied to mean "A windows application which emulates the functionality of the MSDOS command-interpreter (with enhanced functionality)". Unfortunately, since "AWAWETFOTMCI(WEF)" is such a mouthful, many people abbreviate it to "MSDOS" or "DOS". This raises the ire of that sad section of the computing community that is more interested in asserting that MSDOS no longer exists than in communicating effectively.
this one is working fine and simpler
set /p SCHEMAS=<schemas_file.txt
Related
find /? prints:
Searches for a text string in a file or files.
and
findstr /? prints:
Searches for strings in files.
What is the difference between these two?
findstr has way more options than find, for example, /B to look only at the respective beginning of each line. Further, even the matching functionality has a different syntax.
Concerning the question why Microsoft would keep both instead of just extending one with the features of the other I can just speculate:
As a software developer I know that in many cases it is hard to extend an existing command with new features without breaking backwards-compatibility - which is very important when talking about operating systems. So, the easy solution is to introduce a new command and wait for the users to forget about the deprecated one. Which may never happen.
A slightly different explanation can be found for commands like rd and rmdir. While the former is originating from the original MS DOS the latter is part of the UNIX tradition. It makes sense to keep both to make it comfortable for programmers familiar with only one of these. I don't know if there is an explanation in the history of find, though.
i work in a design agency (designer, little knowledge on programming). we have a Windows Server machine (Windows Storage Server 2008) that holds all our jobs. it's going to go under maintenence soon, because it got really slow after a thunderstorm.
however, i'd like to know if there's a native way or something that can be done to find out the latest files/folders created and the space they use. because in the last month, there's been a huge increase in the space usage, coming to something like 20GB in one single day (it shouldn't be more than 4GB/day).
i'm looking for a way to find which jobs are with this unnecessary extra space and help people work the right way.
thank you!
There's no simple way to do this that i know of - however if you're ok with using the command prompt (in the server of course) then this answer from #learnScrapy at SuperUser (with a few tweeks) should do the trick.
Something like:
forfiles /P D:\ /M *.* /S /D +"01/17/2012" /C "cmd /c if #fsize gtr 209715200 echo #path #fsize #fdate #ftime"
You'd need to change D:\ to whatever path you store all your design work at, the date ("01/17/2012") would need to be changed to from whatever date you know the issue wasn't present yet (and maybe change the order depending on the server's regional settings (MM/DD/YYYY vs DD/MM/YYYY vs ....)), and finally change the value 209715200 to whatever minimum size you'd like to search files for - that value is 200MB.
If your projects span multiple files though, if all are smaller then the size you choose but there's just a awful lot of them making up for several GB then you can't know and this won't work. This will only find files with a date later than the one you specified with size larger then the one you specified in the path you specified.
This is bugging me for several days now. I know about the standard stream redirection to the NUL device, but this isn't the case. node.js uses CreateFileW under its fs native/libuv bindings.
Unfortunately using something like:
require('fs').writeFileSync('NUL', 'foo')
creates a NUL file into the cwd that has 3 bytes.
I tried writing to the \Device\Null, but since I'm pretty much a *nix head where everything is a file, I failed to actually find a working path for \Device\Null. Such as \\.\Device\Null that throws ENOENT.
Any ideas about how to make this work under Windows?
This seems to be related, but I can not track the whole flow from lib/fs.js to uv/src/win/fs.c to check that the path argument doesn't suffer from some kind of relative to absolute path resolution.
Valid path to NUL device is "\\\\.\\NUL", not NUL, so the usage is: fs.writeFileSync("\\\\.\\NUL", "foo"). This issue was raised against Node.js on GitHub: https://github.com/nodejs/node-v0.x-archive/issues/9271
Since NUL is a device, not a file, it has to be accessed via device namespace - this requires putting \\.\ in the beginning (the other slashes are for escaping) - see https://msdn.microsoft.com/en-gb/library/windows/desktop/aa365247.aspx#Win32_Device_Namespaces.
There is also a simple dev-null library on NPM that can be used with streams: https://www.npmjs.com/package/dev-null (not with .writeFile though).
There is a long workaround, like code it yourself. But you can take an idea from here https://github.com/hanshuebner/node-hid/blob/master/src/HID.cc and write a wrapper over C library.
I am using the Windows Management Instrumentation Command-line (WMIC) for reading data from a computer like it's Hardware components and IP settings.
As I am using a batch file (Windows) for filling files for each computer/node with data the query logic is implemented there. So far it has been working quite good on my computer and others I have tried on.
The problem is on computers where the WMIC has not been used before, it's neccessary to (automatically) be installed at the first query/execution. This is why the console program prints out "Please wait while WMIC is being installed".
As I am writing to my file this is a problem: I don't want to have this string in it. Another problem is, that if the string is output it crashes all my file. "Please wait while WMIC is being installed" is represented in ASCII, the results of the data queries are somehow written as ASCII characters with leading zeros (multi-byte character set? unicode? ...).
Does someone know how to check if WMIC is alread installed?
Or: how to ignore the string?
Or: do I really have to implement a converter in my file viewer which checks for the string/ character set?
Since that is only printed on the very first run of WMIC, you can just make two calls. One dummy one to eat away the string:
wmic foo >nul 2>&1
and after that what you actually wanted to execute.
I came past a few ways to cause a time delay such as pings and dirs. Though none of them are really precise, is there anny proper way to cause a time delay?
I heard about a few things though they don't work on all computers, not on my Windows XP nor the Windows NT at college.
It takes ages going through all files on Google finding a good answer, and since I didn't yet find the question on Stack Overflow I thought it might be good to just create the question myself ;)
Sleep
It will allow you to do this.
<warning>This is a hack</warning>
Use your favorite programming language (other than MS-DOS batch) and create an application which takes one argument, the number of milliseconds to wait, then, simply call this program from a batch file to sleep the required amount.
As far as I know, this is the only reliable way to do it in DOS.
If you don't have the ability to send another program along with the batch file, use DEBUG to write a sleep command on the fly, and execute it.
EDIT:
The above answer was kind of toungue-in-cheek. I wouldn't run a batch file that had some DEBUG trickery in it. I believe the traditional way to use a delay in a batch file is the CHOICE commad.
type nul|choice /c:y /t:y,nn > nul
Which of course, doesn't work in XP, since that would be WAAYY too convenient.
"...proper way...."
you can't do that in DOS.
It is possible to achieve a precision of a few miliseconds, depending on your machine's speed.
I have just finished creating such a batch, and though I won't share with you the actual code, I'll give you some pointers:
Use %time% variable, and devide into substrings (without ":" and ".") - one substring will get the seconds, the other - minutes (you may add hours, for delays of over an hour, and even incorporate the date)
Use set /A to transform the time variables into 1 integer representing the amount of seconds which have passed since a rounded hour (X:00:00.00). Add the inputed delay (in seconds) to that.
Create a short loop, comparing the value of the combined var (explained in section 2) to the current time (need to recalc the curent combined min+sec value, inside this loop), and exiting the loop when the match is true.
One major bugfix here - you'll need to truncate any preceeding zeros to variables which are about to get evaluated in a "set /A" command. I've noticed that the console's evaluator (for this command) returns an error when an integer with a preceeding 08 or 09 (or simply 08 or 09) is used.
Remark:
This will only work with command extensions enabled. To test it, use the following at the beginning of the routine:
verify other 2>nul
setlocal enableextensions
if errorlevel 1 goto err
And then add an error handler subroutine named "err".
If you'd want to continue your batch in the same file, use "endlocal" after the looping subroutine.
BTW, this applies ONLY to Windows XP service pack 2 or 3.