I'm here to ask you a very strange problem.
Right now i'm starting to work on Salesforce technology, in windows, and currently i follow the tutorial. When finally arrive to the terminal part, Windows come out to create problem...
I state that I am using the terminal of Git Bash Here (MinTTY)
$ sfdx force:data:record:create -s Account -v "Name='Hilton Union Square' BillingStreet='333 O Farrell St' BillingCity='San Francisco' BillingState='CA' BillingPostalCode='94102' Phone='(415) 771-1400' Website='www.hilton.com'"
"C:\Program" non è riconosciuto come comando interno o esterno,
un programma eseguibile o un file batch.
More in general, the problem comes out every time there are Quote in the argument:
$ sfdx ""
"C:\Program" non è riconosciuto come comando interno o esterno,
un programma eseguibile o un file batch.
opposite to:
$ sfdx
Salesforce CLI
VERSION
sfdx-cli/7.157.0 win32-x64 node-v16.15.1
USAGE
$ sfdx [COMMAND]
TOPICS
alias manage username aliases
auth authorize an org for use with the Salesforce CLI
config configure the Salesforce CLI
......
I try almost every thing: alias, Path, Full Path, Short Path, Quote, ...
this is my current path:
PATH=/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/mingw64/bin:/usr/bin:/c/Users/A409806/bin:/c/Program Files/Common Files/Oracle/Java/javapath:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/WINDOWS/System32/WindowsPowerShell/v1.0:/c/WINDOWS/System32/OpenSSH:/c/Program Files (x86)/WindowsPowerShell/Scripts:/cmd:/c/Program Files/nodejs:/c/Users/A409806/AppData/Local/Microsoft/WindowsApps:/c/Program Files/sfdx/bin:/c/Users/A409806/AppData/Roaming/npm:/c/Users/A409806/AppData/Local/Programs/Microsoft VS Code/bin:/c/Users/A409806/AppData/Local/JetBrains/Toolbox/scripts:/usr/bin/vendor_perl:/usr/bin/core_perl
Please, someone help me, i suppose is MinTTY problem, but i can't immage how solve it.
Thanks agane
UPDATE
I expose same problem and find de solution here:
Solution
Related
What is proper procedure to read and output utf8 encoded data in Windows 10?
My attempt to read utf8 encoded file in Windows 10 and output lines into terminal does not reproduce symbols of some languages.
OS: Windows 10
Native codepage: 437
Switched codepage: 65001
In cmd window issued command chcp 65001. Following ruby code reads utf8 encoded file and outputs lines with puts.
fname = 'hello_world.dat'
File.open(fname,'r:UTF-8') do |f|
puts f.read
end
hello_world.dat content
Afrikaans: Hello Wêreld!
Albanian: Përshendetje Botë!
Amharic: ሰላም ልዑል!
Arabic: مرحبا بالعالم!
Armenian: Բարեւ աշխարհ!
Basque: Kaixo Mundua!
Belarussian: Прывітанне Сусвет!
Bengali: ওহে বিশ্ব!
Bulgarian: Здравей свят!
Catalan: Hola món!
Chichewa: Moni Dziko Lapansi!
Chinese: 你好世界！
Croatian: Pozdrav svijete!
Czech: Ahoj světe!
Danish: Hej Verden!
Dutch: Hallo Wereld!
English: Hello World!
Estonian: Tere maailm!
Finnish: Hei maailma!
French: Bonjour monde!
Frisian: Hallo wrâld!
Georgian: გამარჯობა მსოფლიო!
German: Hallo Welt!
Greek: Γειά σου Κόσμε!
Hausa: Sannu Duniya!
Hebrew: שלום עולם!
Hindi: नमस्ते दुनिया!
Hungarian: Helló Világ!
Icelandic: Halló heimur!
Igbo: Ndewo Ụwa!
Indonesian: Halo Dunia!
Italian: Ciao mondo!
Japanese: こんにちは世界！
Kazakh: Сәлем Әлем!
Khmer: សួស្តីពិភពលោក!
Kyrgyz: Салам дүйнө!
Lao: ສະບາຍດີຊາວໂລກ!
Latvian: Sveika pasaule!
Lithuanian: Labas pasauli!
Luxemburgish: Moien Welt!
Macedonian: Здраво свету!
Malay: Hai dunia!
Malayalam: ഹലോ വേൾഡ്!
Mongolian: Сайн уу дэлхий!
Myanmar: မင်္ဂလာပါကမ္ဘာလောက!
Nepali: नमस्कार संसार!
Norwegian: Hei Verden!
Pashto: سلام نړی!
Persian: سلام دنیا!
Polish: Witaj świecie!
Portuguese: Olá Mundo!
Punjabi: ਸਤਿ ਸ੍ਰੀ ਅਕਾਲ ਦੁਨਿਆ!
Romanian: Salut Lume!
Russian: Привет мир!
Scots Gaelic: Hàlo a Shaoghail!
Serbian: Здраво Свете!
Sesotho: Lefatše Lumela!
Sinhala: හෙලෝ වර්ල්ඩ්!
Slovenian: Pozdravljen svet!
Spanish: ¡Hola Mundo!
Sundanese: Halo Dunya!
Swahili: Salamu Dunia!
Swedish: Hej världen!
Tajik: Салом Ҷаҳон!
Thai: สวัสดีชาวโลก!
Turkish: Selam Dünya!
Ukrainian: Привіт Світ!
Uzbek: Salom Dunyo!
Vietnamese: Chào thế giới!
Welsh: Helo Byd!
Xhosa: Molo Lizwe!
Yiddish: העלא וועלט!
Yoruba: Mo ki O Ile Aiye!
Zulu: Sawubona Mhlaba!
Steven Penny suggested to use PowerShell and do not change code page. Following picture demonstrates that the issue persists.
Windows Terminal installer (which is not a part of Windows distribution) solves utf8 output issue, please see included screen capture.
The problem is, you are using a some methods and tools that are really old. First:
Native codepage: 437
Switched codepage: 65001
You don't need to mess with the codepage any more, just leave it as the default. Also, from you picture I see you are also using Console Host, which is also really old. Windows Terminal [1] has been available since 2019, and has built in UTF-8 support. Using Windows Terminal, I can run your script, even without specifying UTF-8:
fname = 'hello_world.dat'
File.open(fname,'r') do |f|
puts f.read
end
and I get perfect result:
To use Windows Terminal, download the msixbundle file [2], then install it. Or, as it's essentially just a Zip file, you can rename it to file.zip and extract it with Windows, then run WindowsTerminal.exe. Or, since you are really having trouble with this process, you can use a portable version I just created
[3] (at your own risk).
https://github.com/microsoft/terminal
https://github.com/microsoft/terminal/releases/tag/v1.8.1444.0
https://github.com/microsoft/terminal/files/6563899/CascadiaPackage_1.8.1444.0_x64.zip
Okay, hopefully I can explain this correctly as I have no idea what's causing this or how to resolve this.
For some reason bash commands (on a CentOS 6.x server) are displaying more information than "normally" and that causes issues with certain scripts. I have no clue if there is a name for this, but hopefully someone knows a solution for this.
First example.
Correct / good server:
[root#goodserver ~]# vzctl enter 3567
entered into CT 3567
[root#example /]#
(this is the correct behaviour)
Incorrect / bad server:
[root#badserver /]# vzctl enter 3127
Entering CT
entered into CT 3127
Open /dev/pts/0
[root#example /]#
With the "bad" server it will display more information as usual, like:
Entering CT
Open /dev/pts/0
It's like it parsing extra information on what it's doing.
Ofcourse the above is purely something cosmetic, however with several bash scripts we use, these issues are really issues.
A part of the script we use, uses the following command (there are more, but this is mainly a example of what's wrong):
DOMAIN=`vzctl exec $VEID 'hostname -d'`
The result of the above information is parsed in /etc/named.conf.
On the GOOD server it would be added in the named.conf like this:
zone "example.com" {
type master;
file "example.com";
allow-transfer {
200.190.100.10;
200.190.101.10;
common-allow-transfer;
};
};
The above is correct.
On the BAD server it would be added in the named.conf like this:
zone "Executing command: hostname -d
example.com" {
type master;
file "Executing command: hostname -d
example.com";
allow-transfer {
200.190.100.10;
200.190.101.10;
common-allow-transfer;
};
};
So it's add stuff of the action it does, in this example "Executing command: hostname -d"
Another example here when I run the command on a good server and on the bad server.
Bad server:
[root#bad-server /]# DOMAIN=`vzctl exec 3333 'hostname -d'`
[root#bad-server /]# echo $DOMAIN
Executing command: hostname -d example.com
Good server:
[root#good-server ~]# DOMAIN=`vzctl exec 4444 'hostname -d'`
[root#good-server ~]# echo $DOMAIN
example.com
My knowledge is limited, but I have tried several things checking rsyslog and the grub.conf, but nothing seems out of the ordinary.
I have no clue why it's displaying the extra information.
Probably it's something simple / stupid, but I have been trying to solve this for hours now and I really have no clue...
So any help is really appreciated.
Added information:
Both servers use: kernel.printk = 7 4 1 7
(I don't know if that's useful)
Well (thanks to Aaron for pointing me in the right direction) I finally found the little culprit which was causing all the issues I experienced with this script (which worked for every other server, so no need to change that obviously).
The issues were caused by the VERBOSE leven set in vz.conf (located in /etc/vz/ directory). There is an option in there called "VERBOSE" and in my case it was set to 3.
According to OpenVZ's website it does the following:
Increments logging level up from the default. Can be used multiple times.
Default value is set to the value of VERBOSE parameter in the global
configuration file vz.conf(5), or to 0 if not set by VERBOSE parameter.
After I changed VERBOSE=3 to VERBOSE=0 my script worked fine once again (as it did for every other server). :-)
So a big shoutout to Aaron for pointing me in the right direction. The answer is easy when you know where to look!
Sorry to say, but I am kinda disappointed by ndim's reaction. This is the 2nd time he was very unhelpful and rude in his response after that. He clearly didn't read the issue I posted correctly. Oh well.
I would make sure to properly parse the output of the command. In this case, we are only interested in lines of the form
entered into CT 12345
One way of doing this would be to pipe everything through sed and having sed print only the number when the line looks as above (untested, and I always forget which braces/brackets/parens need a backslash in front of them):
whateverthecommand | sed -n 's/^entered into CT ([0-9]{1,})$/\1/p'
I'm trying to make a request to a function in a SAP RFC server hosted at 10.123.231.123 with user myuser, password mypass, sysnr 00, client 076, language E. The name of the function is My_Function_Nm with params: string Alternative, string Date, string Name.
I use the command line:
/usr/sap/nwrfcsdk/bin/startrfc -h 10.123.231.123 -s 00 -u myuser -p mypass -c 076 -l en -F My_Function_Nm
But it always shows me the help instructions.
I guess I'm not specifying the -E pathname=edifile, and it's because i don't know how to create a EDI File to include the parameters values to the specified function. Maybe someone can help me on how to create this file and how to correctly invoke startrfc to consume from this function?
Thanks in advance.
If you actually check the help text the problem shows, you should find the following passages:
RFC connection options:
[...]
-2 SNA mode on.
You must set this if you want to connect to R/2.
[...]
-3 R/3 mode on.
You must set this if you want to connect to R/3.
Apparently you forgot to specify -3...
You should use sapnwrfc.ini which will store your connection parameters, and it should be places in the same directory as client program.
Sample file for your app should be following:
DEST=TST1
ASHOST=10.123.231.123
USER=myuser
PASSWD=mypass
SYSNR=076
RFC_TRACE=0
Documentation on using this file is here.
For calling the function you must create Bash-script, but better to use Python script.
In a quick and dirty backup script that's been running fine for years, the registry backup part no longer works. I run the offending code in the command line and get the same result:
C:\>reg export /y HKLM\SOFTWARE\ODBC\ODBC.INI test.reg
ERROR: nombre de clave no válido.
Escriba "REG EXPORT /?" para obtener detalles de uso.
Error translates as "invalid key name". If I lauch regedit and copy the key name to clipboard I get this:
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI
If there is a typo, I'm unable to spot it.
Am I really mistyping the key name? Is there any other reason for the error?
Documentation says this:
Reg export KeyName FileName [/y]
In other words, flags come last:
C:\>reg export HKLM\SOFTWARE\ODBC\ODBC.INI test.reg /y
La operación se ha completado correctamente.
No idea why it's been working before.
I created a local repository with minicpan in a Linux box, and then moved it to a Windows that has no access to online CPAN. But I'm getting this error messages when I try to use it:
cpan> install PowerBuilder::ORCA
Reading 'C:\Perl\minicpan\authors\01mailrc.txt.gz'
Use of uninitialized value $command in concatenation (.) or string at C:\Perl\site\lib/CPAN/Tarzip.pm line 161.
"-qdt" no se reconoce como un comando interno o externo, programa o archivo por lotes ejecutable.
............................................................................DONE
Reading 'C:\Perl\minicpan\modules\02packages.details.txt.gz'
Use of uninitialized value $command in concatenation (.) or string at C:\Perl\site\lib/CPAN/Tarzip.pm line 161.
"-qdt" no se reconoce como un comando interno o externo, programa o archivo por lotes ejecutable.
Warning: Your C:\Perl\minicpan\modules\02packages.details.txt.gz does not contain a Line-Count header.
Please check the validity of the index file by comparing it to more than one CPAN mirror. I'll continue but problems seem likely to
happen.
Caught SIGINT, trying to continue
Warning: Your C:\Perl\minicpan\modules\02packages.details.txt.gz does not contain a Last-Updated header.
Please check the validity of the index file by comparing it to more than one CPAN mirror. I'll continue but problems seem likely to
happen.
Got another SIGINT
Reading 'C:\Perl\minicpan\authors\01mailrc.txt.gz'
Use of uninitialized value $command in concatenation (.) or string at C:\Perl\site\lib/CPAN/Tarzip.pm line 161.
"-qdt" no se reconoce como un comando interno o externo, programa o archivo por lotes ejecutable.
I'm suspecting this could be because of different carriage returns, but if someone has another idea about why this might be, it would be great. Also if it's because of carriage returns, do you have any idea on how to fix this without downloading the whole repository again on a Windows machine?
Delete the CPAN configuration and run its first-time configuration again.
It's still referencing e.g. the Linux path to tar, and using ANSI terminal escapes for colours.