Awkward host name when running Erlang getting started program - cookies

On Windows 7 I have entered and compiled the "tut17" program from the page:
http://www.erlang.org/doc/getting_started/conc_prog.html#id68449
I set the HOME variable to "C:\Users\Name" and I have created a cookie file ".erlang.cookie" in the "C:\Users\Name" directory.
I have started two command prompts as described on the above page. The problem is that the host name is "Name-PC". So when I start the ping process I get a message as follows:
(ping#Name-PC)2> tut17:start_ping(pong#Name-PC).
* 1: variable 'PC' is unbound
How can I get around this problem (presumably) with the hyphen in the host name?

Put pong#Name-PC between ' (single quotes). 'pong#Name-PC' will be interpreted as a single atom rather than the atom pong#Name minus the variable PC.

Related

Google Native Client Visual Studio Add-in: Webserver fails to start because arguments to httpd.py are invalid

I have an application that I turned into a simple Native Client App a year ago, and I've been trying to get it running again. However, when I try to run it, or any of the example VS projects, the web server fails to start, giving me usage hints for httpd.py, and saying "httpd.py: error: unrecognized arguments: 5103".
I wasn't able to find anything about this on the NaCL guide or on the net. I could probably troubleshoot the issue if I could see the script that starts the webserver, but I have no idea where this is stored.
The script that start the server is 'nacl_sdk\pepper_43\tools\httpd.py'. The problem is with the port argument being formated incorrectly.
The expected format is:
httpd.py [-h] [-C SERVE_DIR] [-p PORT] [--no-dir-check]
But, the received arguments formatted by the add-in is:
['--no_dir_check', '5103']
where the port prefix is missing and should be '-p 5103'
For a quick fix, add the following line
parser.add_argument('args', nargs=argparse.REMAINDER)
before the parse_args(args) in the main(args) method in httpd.py.
This will keep the unknown arguments from being parsed and will use the default value for port instead (5103).

Communicate with EPP using wosa xfs

I'm creating a program to communicate with the EPP like if I press any key the application should recognise it and print it back for now for illustration on how to create an application to communicate with the EPP.
Thank you.
I've found what I will call a function on "cwa 14050-6:2005" on page 42 "WFS_CMD_PIN_GET_DATA" and the description states that "This function is used to return keystrokes entered by user." My problem is writing or calling this function and when you go to page 43 on the output param "LPWFSPINDATA lpPinData;" which the "typedef" of it contains I will say a variable "lpPinKeys" which points to an array of pointers to WFSPINKEY structures that contains the keys entered by the user. So after going through this document I saw that in my case I need this, this is because when let's say I key in 1234 enter the application can be able to assign 1234 to a variable so that it can be verified and enter will cause the app to begin the keys verification to see if they match that's from database/server database and if they do then the app will call the relevant service else error will be displayed.
My main problem is calling this within my app. Even if the app can for now display back or assign the keys to a variable from a PIN pad (EPP). For now I don't use any encrypt just want to get and verify the plain keys.
If you require EPP development for NCR machines, you have to use Key Library API. This is not a part of CEN XFS standard, but is explained in the NCR XFS documentation.

vimrc to detect remote connection

At the moment I have to hard code the names of servers on my vimrc in order to either make it different on the remote machine. This is done by conditional statement using hostname() function in vim. I want to make the conditional to be based on the status of remote connection and not on the hostname. So...
The first possible solution I found was using the following bash command in system():
cat /proc/$PPID/status | head -1 | cut -f2
This does not work because I use GNU screen and this will not detect my connection status properly.
The second possible solution I am exploring right now is using who am i This reliably shows whether or not remote connection has been made from which client, but I have trouble getting it working with system()
if substitute(system('who am i'), "theclient", ????, "") == ""
...
How could I get ???? to extract my client name somehow??
Even if the second solution works, allowing me to use .vimrc for many different remote machines, it is still tied to one client. I want the conditional to work in all remote session, regardless of the client name. So I am wondering, is this possible?
The following line allows me to create a variable that detects the remote connection status:
let g:remoteSession = ($STY == "")
Now you can surround the lines that you want to be ignored in the remote connection via:
if g:remoteSession
...
endif
On a side note, I do not know how expensive it is look up the environment variable compared to the global variable, but I am guessing the difference is negligible. The system call in an environment like cygwin where fork() is inefficient, it is worth doing the optimization.
Instead of adding conditional logic to a shared ~/.vimrc, you could alternatively source system-local settings. I use the following:
" Source system-specific .vimrc first.
if filereadable(expand('~/local/.vimrc'))
source ~/local/.vimrc
endif
" Stop sourcing if inclusion guard exists.
if exists('g:loaded_vimrc')
finish
endif
" Common settings of .vimrc here...
I find this more scalable than trying to maintain an ever-changing list of hostnames in a central location.

Why is a Remote WMI call to Win32_Printer Coming Back With An Empty Set For Some Machines?

I am using WMI (prototyping everything in VBScript first, as examples are more plentiful and it removes VBScript/Python impedence) to connect remotely to a fresh PC (we will call this PC2). Most Win32_* classes can be remotely read, yet Win32_Printer returns an empty set when queried, but only when I query remotely. The resulting SWbemObjectSet always has a .Count of zero. No error. I can connect to PC1 and receive a SWbemObjectSet with a non-zero .Count, can iterate through it, etc. If I run the script locally (after removing the superuser username and password from the .ConnectServer method, naturally), I get a non-zero .Count back and can iterate through it. Even if I foolishly use my own Domain Administrator account, the problem persists. The Script:
strComputer = "nnn.nnn.nnn.nnn"
username = "DOMAIN\superuser"
password = "thisisaverygoodpassword"
Set objSWbemLocator = CreateObject("WbemScripting.SWbemLocator")
objSWbemLocator.Security_.ImpersonationLevel = 3
objSWbemLocator.Security_.AuthenticationLevel = 6
Set objSWbemServices = objSWbemLocator.ConnectServer(strComputer, "root\cimv2", username, password)
Set colSWBemObjectSet = objSWbemServices.ExecQuery("Select * From Win32_Printer")
WScript.Echo colSWBemObjectSet.Count & " Found."
For Each objPrinter in colSWBemObjectSet
For Each Property in objPrinter.Properties_
If TypeName(Property.Value) = "Variant()" Then
Wscript.Echo """" & Property.Name & """, """ & TypeName(Property.Value) & """, ""Skipping ..."""
Else
Wscript.Echo """" & Property.Name & """, """ & TypeName(Property.Value) & """, """ & Property.Value & """"
End If
Next
Next
Commenting and error checking have been omitted for brevity.
It does not appear to be a firewall problem.
Reason 1: Where a firewall blockage does exist, I receive an error
back from SWbemLocator, "The RPC server is unavailable."
Reason 2: I can access and run through the WMI class Win32_ComputerSystem
with ease.
It does not appear to be a username/password problem.
Reason 1: I can retrieve information from Win32_ComputerSystem.
Reason 2: I ought to get an error.
It does not appear to be an OS version problem:
Reason: PC2 and PC1 are both running Windows 7 Professional. PC1 is running the 64-bit version, PC2 the 32-bit.
Although I started trying to reach a 32-bit machine from a 64-bit server, it does not appear to be a 32-bit vs. 64-bit problem.
Reason 1: I added a value of 32 for __ProviderArchitecture in a SWbemNamedValueSet prior to my .ConnectServer attempt (with that SWbemNamedValueSet in the arguments to no avail), although I was unable to later add that same context to the .ExecQuery method of the connected server without a type mismatch operator.
Reason 2: I later ran the script from a 32-bit server with the same result.
It does not appear to be a corrupted WMI problem.
Reason: Once I stop using credentials, I can run the script from the target machine itself and receive a result set with more than zero items and can iterate through it.
It does not appear to be a credential/namespace mistake within my script.
Reason: Using WBemTest.exe from the same source machine and using identical username, password, authentication level, impersonation level, namespace, and so forth, I receive the same null set for an answer.
It does not appear to be an issue of WMI Namespace security on the target machine.
Reason 1: Logging in to the target machine with the same credentials as the script uses generates results.
Reason 2: Win32_Printer is in the same namespace as Win32_ComputerSystem. Win32_ComputerSystem works.
Reason 3: After using the Wmimgmt.msc Microsoft Management Console (MMC) to give the superuser full permissions, starting in the root namespace, propagating to "This namespace and subnamespaces," rebooting, and checking again, I still receive the same empty set.
It does not appear to be the respective OUs of PC2 and PC1 that are the problem.
Reason: I swapped the OUs each machine was in and rebooted. No change.
It does not appear to be the Local Computer Groups:
Reason: I made the membership of groups in PC2 look like PC1 and rebooted. No change.
It does not appear to be something magical about Win32_Printer in that remote access does not work.
Reason: I can read PC1's Win32_Printer class.
It does not appear that my WQL is unusual.
Reason: "SELECT * FROM Win32_Printer" is my test case.
It does not appear that my DCOM settings are off.
Reason: They appear identical when I go through PC1 and PC2.
I have even gone so far as to hit the Trace logs in WMI-Activity, print them out for both PC1 and PC2, then sort by GroupOperationID, OperationID (the TimeCreated SystemTime is not granular enough and EventID seems ... out of order. I can see events from the following actions:
IWbemServices::Connect
Start IWbemServices::ExecQuery - Select * from __ClassProviderRegistration
Start IWbemServices::GetObject - __Win32Provider.Name="WmiPerfClass"
Start IWbemServices::ExecQuery - references of {__Win32Provider.Name="WmiPerfClass"}
Start IWbemServices::GetObject - Win32_Printer
Start IWbemServices::ExecQuery - Select * From Win32_Printer
Provider::CreateInstanceEnum - Win32_Printer
in both sets of logs, and if I sort by GroupOperationID, OperationID they appear to happen in identical order. Sorting by EventID shows a somewhat different order. That's the closest I can see to a difference. I'm stumped at this point.
I know this verges perilously close to a system administration issue.
Found this link in the win32_printer spec page referring to this problem http://www.lansweeper.com/forum/yaf_postsm18178_WMI-Security-PowershellLansweeper.aspx#post18178 It appears only printers installes for this user are returned, not all printers on the system. So if you've never logged on to the remote system under the credentials of the user you are using to enumerate the printers then you get an empty result.
Looks like you've had a good shot at it. ServerFault might yield something more...
It's a long shot, but I once heard terminal services being disabled aparently caused issues when issuing WMI queries...
Edit:
This may not apply, but could be worth a look: AD Delegation

popen and system behaves unexpectedly with multiple quoted file paths

I am trying to execute a dos command from within my C++ program, however soon as I add quotes to the output filepath (of a redirection) the command no longer gets executed and returns instantly. I've shown an example below of a path without spaces, but since paths may have spaces and thus be quoted for the shell to understand it properly I need to solve this dilemma - and I'm trying to get the simplest case working first.
i.e.
The following WORKS:
sprintf(exec_cmd,"\"C:/MySQL Server 5.5/bin/mysqldump.exe\" -u%s -p%s %s > C:/backup.bak",user,password,db_name);
system(exec_cmd);
The following does NOT work (notice the quotes around the output):
sprintf(exec_cmd,"\"C:/MySQL Server 5.5/bin/mysqldump.exe\" -u%s -p%s %s > \"C:/backup.bak\"",user,password,db_name);
system(exec_cmd);
I'm guessing it is choking somewhere. I've tried the same "exec_cmd" in popen to no avail.
Any help/advice is greatly appreciated.
I don't think your shell (cmd.exe) allows redirection to a file name with spaces. I couldn't make my command.com from DOS 6.22 accept it (I don't have a cmd.exe nearby to test).
Anyway, you can use the --result-file option to pass the redirection to the command itself.
mysqldump ... --result-file="file name" ...