I want to switch Autocad engine of Design Automation from en-US to ja-JP.
I am having difficulty reading files with accoreconsole english package. I used ja-JP in acccoreconsole command but it failed.
The file read successfully with accoreconsole jp package in local machine, but failed on design automation.
[07/25/2022 01:45:56] Command line: [ /i "T:\Aces\Jobs\31fb798920794a60b245a6dfcde5ab89\input.dxf" /al "T:\Aces\Applications\XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.package" /s "T:\Aces\Jobs\31fb798920794a60b245a6dfcde5ab89\setting_script.scr" /l ja-JP]
[07/25/2022 01:45:56] End preparing script and command line parameters.
[07/25/2022 01:45:56] Start script phase.
[07/25/2022 01:45:56] Start AutoCAD Core Engine standard output dump.
[07/25/2022 01:45:56] Redirect stdout (file: T:\Aces\Jobs\31fb798920794a60b245a6dfcde5ab89\tmp\accc44122).
[07/25/2022 01:45:56] AcCoreConsole: StdOutConsoleMode: processed-output: disabled,auto
[07/25/2022 01:45:56] AutoCAD Core Engine Console - Copyright 2021 Autodesk, Inc. All rights reserved. (S.51.Z.100)
[07/25/2022 01:45:56] Execution Path:
[07/25/2022 01:45:56] T:\Aces\AcesRoot\24.1\coreEngine\Exe\accoreconsole.exe
[07/25/2022 01:45:56] Current Directory: T:\Aces\Jobs\31fb798920794a60b245a6dfcde5ab89
[07/25/2022 01:45:56] Isolating to regkey=HKEY_CURRENT_USER\SOFTWARE\AppDataLow\Software\Autodesk\CoreUser\WorkItem_31fb798920794a60b245a6dfcde5ab89, userDataFolder=T:\Aces\Jobs\31fb798920794a60b245a6dfcde5ab89\userdata.
[07/25/2022 01:45:57] Version Number: S.51.Z.100 (UNICODE)
[07/25/2022 01:45:57] LogFilePath has been set to the working folder.
[07/25/2022 01:45:57] Improper table entry name •Ç1ŠK on line 610.
[07/25/2022 01:45:57] Invalid or incomplete DXF input -- drawing discarded.
[07/25/2022 01:45:57] ERROR: Something went wrong. ErrorStatus=53.
Related
As part of my Jenkins pipeline I want to zip my output directory to a shared drive and I have a batch script that works wonderfully when running it through a shell, but when Jenkins runs it the file_names argument to 7zip goes missing and it zips the entire project folder instead.
The batch script looks as follows, where GGProjectName has a string value(no special characters) and CHANGESET is an integer
set path=D:\Data\Builds\%GGProjectName%\development
call "C:\Program Files\7-Zip\7z.exe" a -tzip %path%\%GGProjectName%-%CHANGESET%.zip .\Build\
Calling the batch script through a shell gives the following output with GGProjectName=ProjectName and CHANGESET=2:
E:\Jenkins\ProjectName\ProjectName_Main\workspace>set path=D:\Data\Builds\ProjectName\development
E:\Jenkins\ProjectName\ProjectName_Main\workspace>CALL "C:\Program Files\7-Zip\7z.exe" a -tzip D:\Data\Builds\ProjectName\development\ProjectName-2.zip E:\Jenkins\ProjectName\ProjectName_Main\workspace\Build\
7-Zip [64] 16.04 : Copyright (c) 1999-2016 Igor Pavlov : 2016-10-04
Scanning the drive:
23 folders, 439 files, 718413046 bytes (686 MiB)
Creating archive: D:\Data\Builds\ProjectName\development\ProjectName-2.zip
Items to compress: 462
Files read from disk: 439
Archive size: 137063321 bytes (131 MiB)
Everything is Ok
Getting Jenkins to run the same script gives the following output, with GGProjectName=ProjectName and CHANGESET=77:
17:04:21 E:\Jenkins\ProjectName\ProjectName_Main\workspace>set path=D:\Data\Builds\ProjectName\development
17:04:21
17:04:21 E:\Jenkins\ProjectName\ProjectName_Main\workspace>CALL "C:\Program Files\7-Zip\7z.exe" a -tzip D:\Data\Builds\ProjectName\development\ProjectName-77
17:05:57
17:05:57 7-Zip [64] 16.04 : Copyright (c) 1999-2016 Igor Pavlov : 2016-10-04
17:05:57
17:05:57 Scanning the drive:
17:05:57 856 folders, 14893 files, 2074486211 bytes (1979 MiB)
17:05:57
17:05:57 Creating archive: D:\Data\Builds\ProjectName\development\ProjectName-77.zip
17:05:57
17:05:57 Items to compress: 15749
17:05:57
17:05:57
17:05:57 Files read from disk: 14893
17:05:57 Archive size: 453305828 bytes (433 MiB)
17:05:57 Everything is Ok
I've identified the issue as Jenkins somehow cutting off the last argument to the call to 7z.exe, though I have no idea what causes it.
The Jenkins stage that runs the script is extremely straightforward so I have a hard time seeing that as the cause.
stage('Deploy') {
steps {
bat 'publish.bat'
}
}
I'm running Jenkins 2.204.2 on a Windows machine.
The main problem is most likely the string value assigned to environment variable CHANGESET which is not just the string 77, but the string 77 with a carriage return or a line-feed or carriage return + line-feed appended which results in a truncated command line on execution by Jenkins. So the source of this problem must be searched in code which defines the environment variable CHANGESET with a string not being only the number, but the number with a newline character.
GG_Victor wrote in a comment:
The carriage return seems to have been the issue and changing the assignment of CHANGESET to have a .trim() on the shell output in the jenkinsfile like so: env.CHANGESET = sh (...).trim() alleviated the issue.
But it would be even better to find out why the environment variable CHANGESET is defined with a string value with a carriage return appended to the number as that is the real source of the issue.
Another issue with the batch code is the redefinition of the predefined environment variable PATH with a string being a single folder path. Please take a look on What is the reason for "X is not recognized as an internal or external command, operable program or batch file"? You should know after reading the long answer from top to bottom why path should not be used as name of a local environment variable. Better would be FolderPath or ProjectPath or ArchivePath instead of path.
So the first line should be for example:
set "ArchivePath=D:\Data\Builds\%GGProjectName%\development"
The usage of " as done here is highly recommended. The reason is described in my answer on:
Why is no string output with 'echo %var%' after using 'set var = text' on command line?
The command CALL is needed only to call a batch file from within a batch file. It is not needed to run an executable from within a batch file. The Windows command processor halts the batch file execution until the started executable terminated itself. So the batch file execution is in your case not continued by cmd.exe until the started 7z.exe finished creating the archive file and terminated with exit code returned back to Windows command processor which assigns it to ERRORLEVEL for evaluation by one of the next commands.
This behavior on starting a console or GUI executable from within a batch file can be seen easily by creating a batch file with following five lines and execute it with a double click:
#echo off
echo Run Notepad.
%SystemRoot%\Notepad.exe
echo Notepad terminated.
pause
The Windows command processor outputs Run Notepad. and starts next Windows Notepad. The console window shows just Run Notepad. as long as the graphical window of Notepad is open because of cmd.exe waits for termination of Windows Notepad. Once Windows Notepad is exited by the user, the Windows command processor continues and outputs next the line Notepad terminated. Last the command execution is paused once more because of command PAUSE to give the user the possibility to see that the batch file execution continued after Notepad termination.
This behavior on starting an executable from within a batch file is different to starting an executable from within a command prompt window. Windows command processor does not wait for termination of the started executable if a user opens a command prompt, enters %SystemRoot%\Notepad.exe and hits key RETURN or ENTER to run Windows Notepad. The user can in this case immediately enter and execute the next command after switching from still opened Notepad window to the Windows command prompt window.
So for the second line should be used:
"C:\Program Files\7-Zip\7z.exe" a -bd -tzip -y -- "%ArchivePath%\%GGProjectName%-%CHANGESET%.zip" ".\Build\"
The double quotes are highly recommended again, especially on full qualified archive file name containing - after a space to avoid getting the rest interpreted by mistake as switch by 7z.exe or on full qualified file name containing a space or one of these characters &()[]{}^=;!'+,`~. It is best to always enclose file/folder names in double quotes even on not being really necessary.
The three additional switches -bd, -y and -- are described in help of 7-Zip.
I am experiencing a very strange behavior, old batch file works well under windows XP. Why doesn't it work when compiling a simple file like hello.c under (Vs2017 + Win10) by a batch file in cmd window?
When realizing that Win10 has new security policy,，I read some articles on Microsoft's website. They recommend using the developer command-line window for command-line compilation.
Indeed, manual operation works well. But when I logged on Win10 as a super administrator and tried to run everything via a batch file,
it didn't work, just finished the environment configuration.
When running the commands in the batch file manually, everything works as expected (executable file successfully generated).
What is wrong with that?
Here is the content of the batch file:
%comspec% /k "C:\Program Files(x86)\Microsoft Visual Studio\2017 \Community\VC\Auxiliary\Build\vcvars64.bat"
cd g:\testdir
g:
cl TestBatFileCompile.c
Preliminary Notes:
vcvars64.bat simply calls vcvarsall.bat and it passes the x64 argument to it, followed by its own (if any)
vcvarsall.bat mainly sets some env vars (set VSCMD_DEBUG=3 prior running it, for verbose output) required for the VStudio build tools to work. Check [MS.Docs]: Build C/C++ code on the command line for more details
I enhanced / simplified your example for more clarity:
script.bat:
#echo off
echo Running vcvars...
%comspec% /K "c:\Install\x86\Microsoft\Visual Studio Community\2017\VC\Auxiliary\Build\vcvarsall.bat" x64
echo Ran vcvars: %ERRORLEVEL%
echo Running cl...
cl /nologo dummy.c /link /NOLOGO
echo Ran cl: %ERRORLEVEL%
dummy.c:
int main() {
return 0;
}
Output:
e:\Work\Dev\StackOverflow\q053523085>dir /b
dummy.c
script.bat
e:\Work\Dev\StackOverflow\q053523085>script.bat
Running vcvars...
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.9.2
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'
e:\Work\Dev\StackOverflow\q053523085>rem HMMM, SOMETHING DOESN'T SEEM QUITE RIGHT. LET'S TRY EXITING CMD...
e:\Work\Dev\StackOverflow\q053523085>exit
Ran vcvars: 0
Running cl...
'cl' is not recognized as an internal or external command,
operable program or batch file.
Ran cl: 9009
What happened?
cmd /K ([MS.Docs]: Cmd) opened a new cmd instance, on top of the existing one (using the same window)
vcvarsall was called in this (2nd) instance, did its job and finished, and things seem to have been left in the air
But after typing exit, it turns out that cl did run, but in the 1st cmd instance (in the background, if you will), and since the variables were not previously set by vcvarsall, it failed
To make things work, invoke vcvarsall using [MS.Docs]: call:
call "c:\Install\x86\Microsoft\Visual Studio Community\2017\VC\Auxiliary\Build\vcvarsall.bat" x64
Output (in a new cmd window):
e:\Work\Dev\StackOverflow\q053523085>dir /b
dummy.c
script.bat
e:\Work\Dev\StackOverflow\q053523085>script.bat
Running vcvars...
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.9.2
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'
Ran vcvars: 0
Running cl...
dummy.c
Ran cl: 0
e:\Work\Dev\StackOverflow\q053523085>dir /b
dummy.c
dummy.exe
dummy.obj
script.bat
I would like to create a batch file to do some instructions in the x64 command prompt of VS13. The instructions are the next ones:
cd C:\SomeDirectory
checkAPIenv AnotherDirectory
cd AnotherDirectory
devenv Projectname.sln
I have created a batch file with them but when I load it in the console, it only does up to checkAPIenv, then does nothing.
I don't see any difference when executing each of those two lines of batch file code
Wscript Test.vbs
Wscript //Nologo Test.vbs
Where is the logo suposed to be located?
Though your question is not clear, I shall tell you the concept of logo/nologo
//logo
Displays a logo when the script runs under CScript (this is the default setting for WSH). The logo, which appears prior to any of the output from the script, looks like this:
Microsoft (R) Windows Script Host Version 5.6Copyright (C) Microsoft
Corporation 1996-2000. All rights reserved.
//nologo
Prevents display of the logo at run time (by default, the logo is displayed).
The //nologo option is often used for scripts whose output is redirected to a text file. Suppressing the logo ensures that this information does not appear within the text file. This makes it easier to write scripts that parse the information found in the text file or that import the contents of the file to a database, because these scripts do not have to account for the logo.
//S
Saves the Timeout and Logo options for this user.
For example, this command ensures that the logo will be suppressed anytime a script runs under CScript:
cscript //nologo //S
You can also modify these settings by right-clicking a script file and then clicking Properties.
Hope you got some benefit from this answer....
windows 7 does not activate the path for powershell.
1) C:\Windows\System32\WindowsPowerShell\v1.0 exsists in my path
C:\GitRepository>path
PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem; C:\Windows\System32\WindowsPowerShell\v1.0;
2) can't run powershell from cmd implicitly
C:\GitRepository>powershell
'powershell' is not recognized as an internal or external command, operable program or batch file.
3) but it runs explicitly
C:\GitRepository>c:\Windows\System32\WindowsPowerShell\v1.0\powershell
Windows PowerShell
Copyright (C) 2009 Microsoft Corporation. All rights reserved.
PS C:\Users\user\Androidwork\WebDevelopment\GitRepository> exit
C:\Users\user\Androidwork\WebDevelopment\GitRepository>
Any idea?
Your problem are the spaces in front of the path to PowerShell. Just remove them, i.e.:
PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;
I found that one of the programs I installed removed the ; in the path separating the Powershell path from the next path. ;C:\Windows\System32\WindowsPowerShell**v1.0\c:**\program files\other program. Once the semi-colon was put into place, powershell.exe launched successfully.