This question already has answers here:
Is it possible to run a command headlessly (in a bat script) as another user on Windows?
(3 answers)
Runas Password in Batchfile
(2 answers)
Closed 4 months ago.
I have a vbscript file that has a username and password input box in it's own window with an OK and Cancel button stacked upon each other. When the user clicks OK to submit the password, I want a new file to open. Here's my code:
set objShell = WScript.CreateObject("WScript.Shell")
strUserName = inputBox("Username")
strPassword = inputBox("Password")
objShell.Run "runas /user:" & strUserName & " ""wscript.exe c:\path\myscript.vbs"" "
Can anybody help me?
If I replace the last line of code, when you click OK, the program closes and nothing happens. The current code opens a command prompt window with the title "C:\Windows\System32\runas.exe" and it just says enter the password for (username you typed) : ex Enter the password for dog :. Whenever you press enter, it closes.
I hope someone more knowledgeable than me answers your question. But in case no one does, here is my take.
I usually find myself pulling my hair out trying to figure out where to put the right number of double quotes, which (speaking from ignorance and therefore with great authority) I bet is why you're experiencing a problem.
So to avoid all that, I suggest either making wscript.exe a default in your system or putting the "wscript.exe c:\path\myscript.vbs" into a .cmd file that the left side of your script runs as an administrator. I bet that either approach will work. Let me know if it doesn't.
Btw, I have sometimes used a subroutine or function that creates a temporary .cmd file which the administrator shell then runs. I hope this helps.
Related
I am creating a text file and looping through every Safari window, every tab, and pasting each link into the .txt file. However I am getting an extra missing value written to the .txt file. I know I can explicitly check for missing values but I don't understand where is the "empty" window/value?
on run {input, parameters}
(* create text file to hold links *)
tell application "Finder" to make file at desktop with properties {name:"links_0"}
set classicPath to (((path to desktop folder) as string) & "links_0")
(* get links of all windows *)
tell application "Safari"
repeat with this_window in windows
set the_URLs to ""
repeat with this_tab in tabs of this_window
set the_URLs to the_URLs & URL of this_tab & return
end repeat
do shell script "echo " & quoted form of the_URLs & " >> " & POSIX path of (classicPath)
do shell script "echo >> " & POSIX path of (classicPath)
end repeat
end tell
return input
end run
sample output (2 windows, each with 2 tabs):
https://discussions.apple.com/thread/64896
https://discussions.apple.com/thread/22543
https://discussions.apple.com/thread/25140
https://discussions.apple.com/thread/22546
missing value
An easier way to do this would be:
set my text item delimiters to linefeed
set fp to POSIX path of (path to desktop folder) & "links_0.txt"
close access (open for access fp) -- Create the file if it doesn't exist
# set eof of fp to 0 -- Erase any existing contents in the file
tell application id "com.apple.Safari" to tell every tab of every window ¬
to tell (the URL as text) & linefeed to continue write it to fp ¬
starting at eof
This currently appends URLs to the end of the file. To overwrite the file, uncomment this line:
# set eof of fp to 0
by removing the hash symbol.
Note: There's potential for confusion having read the comment left by #user3439894, where he states:
"It also shows code missing from CJK's answer in which a file should be closed after being written to. It also wraps relevant code in a try statement so if there is an error it attempts to close the file."
I would take what you read at the provided link with a pinch of salt. Sadly, a lot of the AppleScript documentation from Apple contains code that is poorly written and is part of the reason a lot of bad AppleScript persists so pervasively on the internet. Some of the documentation provided by Apple is also flat out wrong, which makes it very difficult for people to learn from and to know whose advice to take.
The code I have provided above, I assure you, is very much complete. Read on for a pretty boring explanation that I wish I didn't have to give, but now have to:
You'll see a lot of people do this:
set fh to open for access filepath with write permission
write somedata to fh
close access fh
It's not wrong, per se, but it's a pretty draconian way of using these read/write commands, which persists among many simply because they've always done it that way, and only seen it done that way. It's cumbersome and completely unnecessary1.
#user3439894 alluded to a try statement, which would, indeed, be needed for this method. open for access opens a file handle that was necessary in order to write out to a file. However, if an error in the script occurs during the write process, then the file handle is left dangling because the script terminates before being able to close access to the file. The way around this would be to use a try statement whose purpose was to catch an error, and ensure the close access command still gets executed:
try
set fh to open for access filepath with write permission
write somedata to fh
close access fh
on error
close access fh
end try
open for access and close access are redundant. There's no need to use them, and in fact, their use is only creating a potential problem that then needs a workaround in order to solve.
write--and read--are safe and advisable to use on their own, and they don't need a try block to catch potential errors. So why do the two commands I just called redundant appear in my script at all ?
close access (open for access fp)
One nifty side effect of the open for access command is that it will create a file at the specified path if one doesn't already exist. This is really useful because it negates the need to call out to System Events or (shudder) Finder to do this for you. It also has seems to have a wider scope for creating files at locations that other AppleScript applications don't have permission to access if they're sandboxed, etc.
Once open for access has created the file--or opened one that already exists--it returns a reference to the file handle. Then close access is used to immediately destroy file handle, because we don't actually have any use for it, but also don't want it left open. There's also no need for a try block: any error that could possibly arise would do so during the creation of the file handle, which would mean that the file handle won't be created, and so cannot be left open.
1The way the data gets written out now is fundamentally different to how it was written out when these commands were first introduced, and previously, write would not be able to access a file without first explicitly opening a file handle to it and declaring the need for writing permissions. Now, everything gets handled within the write command itself, including clean up.
I am writing a command line code to perform some operations which require a password from the user.I am reading the password from cmd using set/p "pass=>" .
But while using this the password being typed is displayed. I do not want it to be displayed on the cmd window. what modification should i make?
I think CMD does not work in this way. i am guessing you have some sort of a if statement on the inside that will start to run the rest of the program if your input is right. batch files is just a way to get your daily operations faster :)
clsafter "password" typed will prevent people from seeing the password after it was entered.
or maybe this post can help you:
Can I mask an input text in a bat file
This question already has answers here:
How to save Excel Workbook to Desktop regardless of user?
(3 answers)
Closed 8 years ago.
I have a spreadsheet that I want to use a macro to 'save as PDF' in Excel 2010, always saving to the desktop.
I have successfully been able to read the username of the computer using 'Environ' function, however, due to the different location of the desktop folder on Windows 7 and Windows XP it will not always work.
Is there a way to get the operating system to be read like the username? Then I can have an IF( OS=W7 , C:/Users.... , C:/Docs... ) to set the file path.
My plan is to display these in cells, then concatenate these cells into a single string and read that in the macro for the entire save filepath and name.
Thanks a lot in advance,
Doug.
Function userDesktop() As String
Dim oWH As Object
Set oWH = CreateObject("WScript.Shell")
userDesktop = oWH.SpecialFolders("Desktop")
End Function
I want to start a console program via batch script. Starting the console program works fine. I am starting it via call xxx.exe para para. The problem is that the console program wants an input like that after it is started.
call xxx.exe para para
please type in password:_
Is it possible to make the input of the password from the batch script.
Whether you are using batch or bash, as it seemed originally, you could try this simple piping:
echo YourPassword| program.exe parameters...
Note that if it is indeed a batch script, it is vital to make sure there's no extra space between your password and the |, or it will be passed along with the password, as part of the password. In bash, if I'm not much mistaken, such a space would be disregarded (or maybe it would only be so if you enclosed the echoed string in quotation marks, I'm not entirely sure).
Anyway, the above doesn't always work, as some programs implement password reading in a way that disregards the input stream piped from another command.
You tagged your question "Windows" and "Batch" and asked about "batch" in the question. The answer to that question is: Yes, use set like this:
set /p password=please type in password:
If you're really asking about 'bash' shell, you should re-tag your question (and change the text).
I swear this assignment will be the end of me, I've been researching this new problem for the greater part of the day and getting quite stuck. The problem is as follows: we've been tasked with finding a command that will open a new cmd window and change the color (both foreground and background), AND the prompt. The lecturer specified the use of the 'cmd' command however: I can't find the switches (if that's the correct term) or parameters to use. I did find that--
START COLOR A4
did the correct sort of thing, however this is using the incorrect command and when trying to add a second parameter:
START COLOR A4 PROMPT $V
It did not work correctly. This may partly be due to my lack of knowledge on the use of delimiters and how to send in multiple parameters to a command.
Thanks in advance for the help. JohnW.
A couple of hints should sort you out:
START COLOR A4
is shorthand for
START cmd /k "COLOR A4"
See the syntax for cmd and pay special attention to the Remarks section - it tells you how to issue multiple commands.