I am using cm synergy 7.1.
I have to rename a file from say x to y.
But there is no option(not even in right click menu) in synergy GUI for renaming files.
So I am using CLI.
When I try to move it to a new file it gives me below error:
# ccm move x y
Warning: No sessions found.
Please run 'ccm start' to start a session.
When I try to start ccm session it gives me error:
ccm start -h ccm-srv -d /dbs/db1 -m -q -rc -nogui
Warning: bad rfc address (ccm-srv:8830)
Warning: Engine startup failed.
Warning: IBM Rational Synergy startup failed.
When I try to move file using cmsynergy71 command it just opens synergy gui.
cmsynergy71 move x y
What am I missing and how to rename a file?
To rename a file in synergy GUI first you must checkout the file, then there is an option to rename.
Not sure about the CLI. Looks like you need to provide it a qualified server address not just your hostname.
Related
Trying to trigger scans from fujitsu ScanSnap iX500 using CLI, defining a specific scanner.
scanimage --device 'fujitsu:ScanSnap iX500:[s/n]' --resolution 300 --batch=Scan-p%d.pnm --format=pnm --mode color
The error from that: scanimage: open of device fujitsu:ScanSnap iX500:[s/n] failed: Invalid argument
The --device entry was derived from sudo scanimage -L
The following variations of --device return the same error:
fujitsu:ScanSnap iX500
fujitsu:ScanSnap
fujitsu
Removing the --device option removes the error, BUT causes the command to search for a locally-attached device, which introduces a long delay. Targeting the --device in the hopes of eliminating the delay.
From https://linux.die.net/man/1/scanimage : there is no parameter "--device" for the scanimage command.
Maybe you want to use -d or --device-name and follow the advices given in the manual:
The -d or --device-name options must be followed by a SANE device-name like 'epson:/dev/sg0' or 'hp:/dev/usbscanner0'. A (partial) list of available devices can be obtained with the --list-devices option (see below). If no device-name is specified explicitly, scanimage reads a device-name from the environment variable SANE_DEFAULT_DEVICE. If this variable is not set, scanimage will attempt to open the first available device.
The problem, it turns out, was not in the naming of the device. (The name returned by sudo scanimage -L is the correct one to use and works fine.
The issue has to do with permissions / user
Running the command under the .sh file used appropriate permissions. Running directly in command line must have used another user, even though both were executed under the same ssh session.
Solution: Choose the right login user. In my case adding sudo before the command (which was not included or necessary in the .sh file) resolved the issue.
I'm using two files:
1- .bat file which contains in one line:
"C:\Path_to\putty.exe" -ssh servername -l myuserid -pw my password -m "C:\Path_to_Commands_File\Commands.txt" -t
2- Commands.txt which contains either one of these commands:
Command#1:
/Path_to_sasprogram/sasprogram.sas
OR
Commands#2 in the following order:
cd /Path_to_sasprogram/
sas sasprogram.sas
However, the sasprogram.sas does not get executed. So, I used putty to manually execute the commands above. With the commands#2, I get this error: "sas: command not found".
Any suggestions/help would be greatly appreciated! BTW, I tried some solutions already posted, but they didn't work for me. Thanks
It sounds like sas is not on the path of your session.
try
/path_to_sas_executable/sas sasprogram.sas
I am trying to create a svnserver using cmd after i changed svnserve.conf by uncommenting the following lines in the file,
anon-access = read
auth-access = write
command execute in cmd is,
sc create svnserver binpath= "C:\Program Files\TortoiseSVN\bin\svnserve.exe --service -r c:\Goods\Repo" DisplayName= "Subversion" depend= tcpip start= auto
but i am getting error
'sc' is not recognized as an internal or external command
I am not sure what i am doing wrong. I have installed tortoise SVN Client and Visual SVN Server.
Can someone please let me know what i am missing here.
you will need to add the path to sc.exe ("c:\windows\system32\") in your Path environment variable. Do this by hitting windows key + Pause|Break then selecting advanced system settings - environment variables is at the bottom. Just add an extra entry after the last - separated by semi-colons. If this isn't possible, simply give the command the full path of sc.exe e.g.
"c:\windows\system32\sc.exe" create svnserver....
I'm having a problem debugging a command line program on OS X. I've used this same source file with the same g++ command line hundreds of times to test things with the Crypto++ library.
Under GDB, I get the following after loading the EXE:
$ gdb ./cryptopp-test.exe
...
(gdb) r
Starting program: /Users/jwalton/cryptopp-test.exe
Unable to find Mach task port for process-id 42811: (os/kern) failure (0x5).
Under LLDB, I get the following:
$ lldb ./cryptopp-test.exe
Current executable set to './cryptopp-test.exe' (x86_64).
(lldb) r
error: initial process state wasn't stopped: exited
I've recompiled the program a few times, and I can't get it to run under a debugger. I'm getting a segfault when trying to run outside the debugger too, so that may be a symptom here also.
OS X is 10.8.5, and Xcode is 5.1.1 (5B1008). Everything is fully patched. The only thing to change recently is signing up for a developer account, which is broken thanks to Apple's DRM crap. I can't seem to get any of it to work with Xcode or the command line even though Roots and Certificates are in my Keychain. But this program does not use code signing.
What is causing the initial process state wasn't stopped: exited error, and how do I fix it?
The errors that you have received are usually a direct correlation of a codesigning issue, not with your executable, but with gdb and lldb themselves.
You have a couple of options:
Launch gdb or lldb as sudo (which ignores the codesign req to run executables)
Create a codesigning certificate for gdb or lldb in Keychain.app
Obviously the first option is quickest, but probably should be avoided as it opens up the possibility of bad things happening with elevated permissions.
With option #2 you can likely get gdb or lldb properly working by doing this:
Launch /Applications/Utilities/Keychain Access.app
Select the Keychain Access -> Certificate Assistant -> Create a Certificate...
Choose a name for the new certificate (for example lldb-cert or gdb-cert)
Set Identity Type to Self Signed Root
Set Certificate Type to Code Signing
Select the Let me override defaults option
Continue until the "Specify a Location For The Certificate" screen appears
Set Keychain to System and Continue
In the view showing your certificates, double-click on the one just created and then set "When using this certificate" to "Always Trust"
In Terminal:
codesign -f -s "gdb-cert" /path/to/gdb (or) "lldb-cert" /path/to/lldb
You might have to restart for this to effectively take hold.
There are more concise instructions here for gdb and here for lldb on the codesigning process.
I successfully compiled a MUD source code, and it says in the instructions to start up the server using
nohup ./startup &
although when I do this it gives me this error:
$ nohup: ignoring input and appending output to `nohup.out'
nohup: failed to run command `./startup': Permission denied
I have looked all over the internet to find the answer. A few of them said to put my cygwin directory in the root folder (I am using windows 7) and its directory is C:\cygwin
so thats not a problem.. Can anyone help me with this please??
Try chmod +x startup, maybe your startup file is not executable.
From "man nohup":
If the standard output is a terminal, all output written by the named
utility to its standard output shall be appended to the end of the
file nohup.out in the current directory. If nohup.out cannot be
created or opened for appending, the output shall be appended to the
end of the file nohup.out in the directory specified by the HOME
environment variable. If neither file can be created or opened for
appending, utility shall not be invoked. If a file is created, the
file's permission bits shall be set to S_IRUSR | S_IWUSR.
My guess is that since "sh -c" doesn't start a login shell, it is inheriting the environment of the invoking shell, including the HOME environment variable, and is trying to open it there. So I would check the permissions of both your current directory and $HOME. You can try to touch test.txt in current directory or $HOME to see if you can perform that command.
As staticx writes, check the permissions of the directory (and the user) - and the executable.
Instead of using nohup:
check if nohup is needed at all, try ./startup </dev/null >mud.out 2>mud.err &, then close the terminal window and check if it is running
or just run ./startup in a screen session and detach it (<ctrl>+<a>,<d>)