Here is a simple program that reads lines from stdin and outputs them to stdout.
module test;
import std.stdio;
void main(string[] args)
{
foreach (int i, string line; lines(stdin)) {
writeln(line ~ " (test)");
}
}
I'm using the Windows DMD compiler v2.052.
If I do : type file.txt | test.exe
The program appends the word "test" to each line of file.txt and outputs them to the console.
However I keep getting an error at the end:
std.stdio.StdioException#std\stdio.d(2138): Bad file descriptor
Maybe I'm missing something?
It drives me crazy! :)
This is a longstanding bug: http://d.puremagic.com/issues/show_bug.cgi?id=3425
What you're trying to do definitely works on non-Windows operating systems and should work on Windows, too. I think it's a bug in the Digital Mars implementation of the C I/O functions, which are being wrapped by std.stdio. I've tried to fix this bug before, but never even succeeded in identifying its root cause.
I'm not familiar with the type command, maybe it isn't sending EOF when the file is done. In Linux you just do: ./test < file.txt
This is input redirection. Unlike piping, which turns the program output into standard input, this turns the file into standard input of the program. There is also output redirection which takes the output of the program and stores it in a file.
./test > output.txt
Related
I would like to redirect the stdout to null when loading package in Windows Tcl. (Redirect the wording of "Quality Windows Audio/Video Experience (qWAVE) support is available." to null)
Is their any way to solve this or any idea for this ?? Thank you so much.
C:\Users\Tester>tclsh
% set ixchariot_installation_dir "C:/Program Files x86)/Ixia/IxChariot"
C:/Program Files (x86)/Ixia/IxChariot
% cd $ixchariot_installation_dir
% load ChariotExt
Quality Windows Audio/Video Experience (qWAVE) support is available.
If the library is using Tcl channels to write its message, and you're using Tcl 8.6, it's pretty easy. You just push a transform on the stdout channel that swallows all bytes.
# Most of this is boiler-plate stuff...
namespace eval swallow {
proc initialize {handle mode} {
return {initialize clear finalize write flush}
}
proc clear {handle} {}
proc finalize {handle} {}
proc flush {handle} {}
# The important one; do nothing to throw away bytes
proc write {handle buffer} {}
# Export as an ensemble
namespace export *
namespace ensemble create
}
# Start dropping output
chan push stdout swallow
load ChariotExt
# Stop dropping output
chan pop stdout
That only works if the library is using Tcl channels to write it's message. If it is using a direct write (the more likely case) it won't. You can instead try a full redirect, but these are not easily undone.
close stdout
open NUL
load ChariotExt
I know that'd work on POSIX systems (except with /dev/null instead of NUL). Not sure on Windows. And it can't be easily undone; the old standard output stream is gone.
And in any case, it's possible that the library is using a direct write to the console; those aren't blockable, and you might just have to live with that irritating message.
I want to make a command line tool by Flash Air, but there is not any api of AS3 to output content to standard output.
Then, I try to use ANE to solve my problem(By making a windows ane and use C's printf function to output content), but it doesn't work.
Is there any methods to use the standard output by Flash air, or to make a command line tool by Flash Air?
The code of dll written by c++ is:
FREObject add(FREContext ctx, void* functionData, uint32_t argc, FREObject argv[])
{
int32_t x,y;
FREGetObjectAsInt32(argv[0], &x);
FREGetObjectAsInt32(argv[1], &y);
int32_t result = x + y;
FREObject resObj;
FRENewObjectFromInt32(result, &resObj);
//I want to use the "printf" to print content to the console
printf("print by dll: the result is %d\n", result);
return resObj;
}
but there is not any api of AS3 to output content to standard output.
Only a running OS process can give back Standard Output (also called stdio in C).
The best you can do is create an app that looks like commandline tool but in reality it just runs & passes data to the actual (native) OS commandline tool. Meaning in your tool you capture the user command to a string and then run a nativeProcess involving that (parsed) string as your process arguments.
Example in your app user types : calc. Your AIR runs: c:\Windows\System32\calc.exe
Anyways, on to your real question...
I try to use C's printf function to output content, but it doesn't
work.
If you mean you made some test.exe with C and when you get AIR to run it you want to capture the printf output then you can try:
process.addEventListener(ProgressEvent.STANDARD_OUTPUT_DATA, CTest_OutputData);
or
process.addEventListener(ProgressEvent.STANDARD_ERROR_DATA, CTest_ErrorData);
To catch the output (it will be sent as bytes) make sure you have some public byteArray and String created. Here's an example for STANDARD_ERROR_DATA (it's likely the output goes here too, since you claim that STANDARD_OUTPUT_DATA is not working).
The code shown below inside that function works same whichever type of progressEvent you choose. Just put in the "right" one. temp_BA is the byteArray variable you setup earlier.
public function CTest_ErrorData (event:ProgressEvent):void
{
process.standardOutput.readBytes( temp_BA, temp_BA.length, process.standardOutput.bytesAvailable );
if ( temp_BA.length > 0 )
{
temp_String = temp_BA.readUTFBytes(temp_BA.length);
trace( "temp_String is : " + temp_String ); //if you want to check it
}
}
Final TIP: You can get traces inside Flash IDE by disabling "desktop" and keeping "extended desktop" ticked. Both must be ticked later when you make installing app.
I am running my fedora on VMware Workstation. I am having a lex and yacc program. Compilation of program is working fine but when i go to run the program through gcc y.tab.c lex.yy.c -ll it gives fatal error: y.tab.h: No such file or directory.
Same program is working fine with red hat but not in fedora which is running on VMware.
Please give some suggestions.
This program is a infix to post fix program.
lex program:---->
%{
#include<string.h>
#include"y.tab.h"
FILE *fp,*yyin;
%}
%%
"*"|"/"|"+"|"-"|"("|")" {return yytext[0];}
[0-9]+ {yylval.name=(char*)malloc(yyleng+1);
strcpy(yylval.name,yytext);
return num;}
\n {return(0);}
[a-zA-Z][a-zA-Z]* {yylval.name=(char*)malloc(yyleng+1);
strcpy(yylval.name,yytext);
return ID;}
. {}
%%
int yywrap()
{
return 1;
}
yacc program:------->
%{
#include<stdio.h>
#include<string.h>
%}
%union
{
char *name;
}
%token<name>num ID
%type<name>E
%left'+''-'
%left'*''/'
%nonassoc UMINUS
%%
S:E{printf("\n%s",$1);}
;
E:E'*'E {strcpy($$,strcat(strcat($1,$3),"*"));}
|E'/'E {strcpy($$,strcat(strcat($1,$3),"/"));}
|E'+'E {strcpy($$,strcat(strcat($1,$3),"+"));}
|E'-'E {strcpy($$,strcat(strcat($1,$3),"-"));}
|ID
|num
|'-'E%prec UMINUS {strcpy($$,strcat($2,"UMINUS"));}
|'('E')'{strcpy($$,$2);}
;
%%
main()
{
yyparse();
}
int yyerror(char *s) {fprintf(stderr,"%s\n",s);}
This is likely to be a problem with exactly which commands you use to invoke Yacc, Lex and GCC, and not with the input files that you included here.
Yacc (which probably really is a program called Bison even if you use the command yacc) generates two files: A parser (y.tab.c) and another file (y.tab.h) with definitions that the scanner needs. The problem here is that GCC cannot find that file, y.tab.h.
Check these things:
That the file actually is generated. You may have to give the flag -d to Bison/Yacc.
That the file is called y.tab.h. The name can be different depending on program versions, and if you start Bison with the command bison or with the command yacc.
That the file is in a directory where GCC can find it.
If you are using flex windows(lex and yacc) on windows and facing this error then fillow the given steps:
In lex file on first line add this line:
%option noyywrap
compile the lex file
compile the yacc file
then compile and build the yacc file
select the option "open with cmd"
Enter the commond:
filename.exe
please note that lex file name and yacc file name should be same only they differ in their extensions
In lex file change "y.tab.h" to which your bison generate the blahblah.tab.h
and run according enter image description here
I am trying to use the Ocaml csv library. I downloaded csv-1.2.3 and followed the installation instructions after installing findlib:
Uncompress the source archive and go to the root of the package,
Run 'ocaml setup.ml -configure',
Run 'ocaml setup.ml -build',
Run 'ocaml setup.ml -install'
Now I have META, csv.a, csv.cma, csv.cmi, csv.cmx, csv.cmxa, csv.mli files in ~/opt/lib/ocaml/site-lib/csv repertory. The shell command ocamlfind list -describe gives csv A pure OCaml library to read and write CSV files. (version: 1.2.3) which I believe means that csv is installed properly.
BUT when I add
let data = Csv.load "foo.csv" in
in my compute.ml module and try to compile it within the larger program package I have the compilation error :
File "_none_", line 1, characters 0-1:
Error: No implementations provided for the following modules:
Csv referenced from compute.cmx"
and if I simply type
let data = load "foo.csv" in
i get :
File "compute.ml", line 74, characters 13-17:
Error: Unbound value load
I have the same type of errors when I use Csv.load or load directly in the Ocaml terminal. Would somebody have an idea of what is wrong in my code or library installation?
My guess is that you're using ocamlfind for compilation (ocamlfind ocamlc -package csv ...), because you have a linking error, not a type-checking one (which would be the case if you had not specified at all where csv is). The solution may be, in this case, to add a -linkall option to the final compilation line producing an executable, to ask it to link csv.cmx with it. Otherwise, please try to use ocamlfind and yes, tell us what your compilation command is.
For the toplevel, it is very easy to use ocamlfind from it. Watch this toplevel interaction:
% ocaml
Objective Caml version 3.12.1
# #use "topfind";;
- : unit = ()
Findlib has been successfully loaded. Additional directives:
#require "package";; to load a package
#list;; to list the available packages
#camlp4o;; to load camlp4 (standard syntax)
#camlp4r;; to load camlp4 (revised syntax)
#predicates "p,q,...";; to set these predicates
Topfind.reset();; to force that packages will be reloaded
#thread;; to enable threads
- : unit = ()
# #require "csv";;
/usr/lib/ocaml/csv: added to search path
/usr/lib/ocaml/csv/csv.cma: loaded
# Csv.load;;
- : ?separator:char -> ?excel_tricks:bool -> string -> Csv.t = <fun>
To be explicit. What I typed once in the toplevel was:
#use "topfind";;
#require "csv";;
Csv.load;; (* or anything else that uses Csv *)
I tried messing around with Win32 binaries lately (this is for a big project of mine).
So after some weeks of research, I now have a solid understanding of how Assembly works, how it is converted into binary code and how x86/x64 opcodes work.
The last piece to the puzzle is figuring out how to properly call Win32 API methods.
I actually asked a question on here in relation to this, and the answer I got was, I should try and compile an Assembly or C program that does this. So I went ahead and tried this in Assembly (I'm using FASM by the way):
format PE console
entry start
section '.idata' import data readable writable
include 'win32a.inc'
library kernel,'kernel32.dll'
import kernel,\
GetStdHandle,'GetStdHandle',\
WriteConsoleA,'WriteConsoleA'
section '.data' data readable writable
string db 'Hello!', 0h
output dd ?
section '.code' code readable executable
start: push -11
call GetStdHandle
pushd 0
pushd output
pushd 7
pushd string
pushd eax
call WriteConsoleA
This is one of the many versions of this code actually. The main problem is, when I call methods like "ExitProcess", generally other functions from the kernel32.dll library, things seem to work out. It's the IO functions that bug me...
I don't understand what's wrong with this code, I don't get any compile-time errors, though when I run it, it just crashes.
So my next idea was, since this didn't work, to try the same in C.
I'm using Cygwin as a compiler and linker...
#include <windows.h>
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {
MessageBox(NULL, "Hello, world!", "Test", MB_OK);
return 0;
}
This code yielded the same result, the application crashed.
Now, I am not looking for any C/C++ code. My original question of interest was to know how calling extern library function looks like in x86/x64 binary (assembled) code. But I would be very thankful for any resources regarding this topic.
Thank you in advance.
-Tom S.
Your problem is that you need to call ExitProcess at the end to properly end the process. Since you are not doing that, the code currently will continue executing and eventually segfaults because it attempts to execute junk bytes.