nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
Code Issues Projects Releases Wiki Activity
0.82
putty-source/unix/printing.c

59 lines
1.2 KiB
C
Raw Permalink Normal View History

First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
/*
* Printing interface for PuTTY.
*/
#include <assert.h>
Printer support: cfg.printer is assumed to be a Unix command through which to pipe printed data. Of course by default printing is disabled; typically cfg.printer would be set to `lpr', perhaps with some arguments. [originally from svn r2073]
2002-10-15 17:38:04 +00:00
#include <stdio.h>
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
#include "putty.h"
Printer support: cfg.printer is assumed to be a Unix command through which to pipe printed data. Of course by default printing is disabled; typically cfg.printer would be set to `lpr', perhaps with some arguments. [originally from svn r2073]
2002-10-15 17:38:04 +00:00
struct printer_job_tag {
FILE *fp;
};
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
printer_job *printer_start_job(char *printer)
{
Rename 'ret' variables passed from allocation to return. I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no longer fond of the variable name 'ret', because it's used in two quite different contexts: it's the return value from a subroutine you just called (e.g. 'int ret = read(fd, buf, len);' and then check for error or EOF), or it's the value you're preparing to return from the _containing_ routine (maybe by assigning it a default value and then conditionally modifying it, or by starting at NULL and reallocating, or setting it just before using the 'goto out' cleanup idiom). In the past I've occasionally made mistakes by forgetting which meaning the variable had, or accidentally conflating both uses. If all else fails, I now prefer 'retd' (short for 'returned') in the former situation, and 'toret' (obviously, the value 'to return') in the latter case. But even better is to pick a name that actually says something more specific about what the thing actually is. One particular bad habit throughout this codebase is to have a set of functions that deal with some object type (say 'Foo'), all *but one* of which take a 'Foo *foo' parameter, but the foo_new() function starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the canonical name for the ambient Foo is 'foo', so should foo_new()! So here's a no-brainer start on cutting down on the uses of 'ret': I looked for all the cases where it was being assigned the result of an allocation, and renamed the variable to be a description of the thing being allocated. In the case of a new() function belonging to a family, I picked the same name as the rest of the functions in its own family, for consistency. In other cases I picked something sensible. One case where it _does_ make sense not to use your usual name for the variable type is when you're cloning an existing object. In that case, _neither_ of the Foo objects involved should be called 'foo', because it's ambiguous! They should be named so you can see which is which. In the two cases I found here, I've called them 'orig' and 'copy'. As in the previous refactoring, many thanks to clang-rename for the help.
2022-09-13 13:53:36 +00:00
printer_job *pj = snew(printer_job);
Printer support: cfg.printer is assumed to be a Unix command through which to pipe printed data. Of course by default printing is disabled; typically cfg.printer would be set to `lpr', perhaps with some arguments. [originally from svn r2073]
2002-10-15 17:38:04 +00:00
/*
printer_start_job shouldn't need to refer to cfg.printer, since it's getting the printer name passed in anyway! Oops. [originally from svn r2563]
2003-01-12 14:50:34 +00:00
* On Unix, we treat the printer string as the name of a
* command to pipe to - typically lpr, of course.
Printer support: cfg.printer is assumed to be a Unix command through which to pipe printed data. Of course by default printing is disabled; typically cfg.printer would be set to `lpr', perhaps with some arguments. [originally from svn r2073]
2002-10-15 17:38:04 +00:00
*/
Rename 'ret' variables passed from allocation to return. I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no longer fond of the variable name 'ret', because it's used in two quite different contexts: it's the return value from a subroutine you just called (e.g. 'int ret = read(fd, buf, len);' and then check for error or EOF), or it's the value you're preparing to return from the _containing_ routine (maybe by assigning it a default value and then conditionally modifying it, or by starting at NULL and reallocating, or setting it just before using the 'goto out' cleanup idiom). In the past I've occasionally made mistakes by forgetting which meaning the variable had, or accidentally conflating both uses. If all else fails, I now prefer 'retd' (short for 'returned') in the former situation, and 'toret' (obviously, the value 'to return') in the latter case. But even better is to pick a name that actually says something more specific about what the thing actually is. One particular bad habit throughout this codebase is to have a set of functions that deal with some object type (say 'Foo'), all *but one* of which take a 'Foo *foo' parameter, but the foo_new() function starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the canonical name for the ambient Foo is 'foo', so should foo_new()! So here's a no-brainer start on cutting down on the uses of 'ret': I looked for all the cases where it was being assigned the result of an allocation, and renamed the variable to be a description of the thing being allocated. In the case of a new() function belonging to a family, I picked the same name as the rest of the functions in its own family, for consistency. In other cases I picked something sensible. One case where it _does_ make sense not to use your usual name for the variable type is when you're cloning an existing object. In that case, _neither_ of the Foo objects involved should be called 'foo', because it's ambiguous! They should be named so you can see which is which. In the two cases I found here, I've called them 'orig' and 'copy'. As in the previous refactoring, many thanks to clang-rename for the help.
2022-09-13 13:53:36 +00:00
pj->fp = popen(printer, "w");
if (!pj->fp) {
sfree(pj);
pj = NULL;
Printer support: cfg.printer is assumed to be a Unix command through which to pipe printed data. Of course by default printing is disabled; typically cfg.printer would be set to `lpr', perhaps with some arguments. [originally from svn r2073]
2002-10-15 17:38:04 +00:00
}
Rename 'ret' variables passed from allocation to return. I mentioned recently (in commit 9e7d4c53d80b6eb) message that I'm no longer fond of the variable name 'ret', because it's used in two quite different contexts: it's the return value from a subroutine you just called (e.g. 'int ret = read(fd, buf, len);' and then check for error or EOF), or it's the value you're preparing to return from the _containing_ routine (maybe by assigning it a default value and then conditionally modifying it, or by starting at NULL and reallocating, or setting it just before using the 'goto out' cleanup idiom). In the past I've occasionally made mistakes by forgetting which meaning the variable had, or accidentally conflating both uses. If all else fails, I now prefer 'retd' (short for 'returned') in the former situation, and 'toret' (obviously, the value 'to return') in the latter case. But even better is to pick a name that actually says something more specific about what the thing actually is. One particular bad habit throughout this codebase is to have a set of functions that deal with some object type (say 'Foo'), all *but one* of which take a 'Foo *foo' parameter, but the foo_new() function starts with 'Foo *ret = snew(Foo)'. If all the rest of them think the canonical name for the ambient Foo is 'foo', so should foo_new()! So here's a no-brainer start on cutting down on the uses of 'ret': I looked for all the cases where it was being assigned the result of an allocation, and renamed the variable to be a description of the thing being allocated. In the case of a new() function belonging to a family, I picked the same name as the rest of the functions in its own family, for consistency. In other cases I picked something sensible. One case where it _does_ make sense not to use your usual name for the variable type is when you're cloning an existing object. In that case, _neither_ of the Foo objects involved should be called 'foo', because it's ambiguous! They should be named so you can see which is which. In the two cases I found here, I've called them 'orig' and 'copy'. As in the previous refactoring, many thanks to clang-rename for the help.
2022-09-13 13:53:36 +00:00
return pj;
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
}
Make bufchain_prefix return a ptrlen. Now that all the call sites are expecting a size_t instead of an int length field, it's no longer particularly difficult to make it actually return the pointer,length pair in the form of a ptrlen. It would be nice to say that simplifies call sites because those ptrlens can all be passed straight along to other ptrlen-consuming functions. Actually almost none of the call sites are like that _yet_, but this makes it possible to move them in that direction in future (as part of my general aim to migrate ptrlen-wards as much as I can). But also it's just nicer to keep the pointer and length together in one variable, and not have to declare them both in advance with two extra lines of boilerplate.
2019-02-06 20:46:45 +00:00
void printer_job_data(printer_job *pj, const void *data, size_t len)
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
{
Printer support: cfg.printer is assumed to be a Unix command through which to pipe printed data. Of course by default printing is disabled; typically cfg.printer would be set to `lpr', perhaps with some arguments. [originally from svn r2073]
2002-10-15 17:38:04 +00:00
if (!pj)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return;
Printer support: cfg.printer is assumed to be a Unix command through which to pipe printed data. Of course by default printing is disabled; typically cfg.printer would be set to `lpr', perhaps with some arguments. [originally from svn r2073]
2002-10-15 17:38:04 +00:00
Update to r8614: another -D_FORTIFY_SOURCE=2 fix. [originally from svn r8875] [r8614 == 4bddcc2b5dd6467ce9aa8bebea9ceedcda8903e5]
2010-02-20 11:21:25 +00:00
if (fwrite(data, 1, len, pj->fp) < len)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
/* ignore */;
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
}
void printer_finish_job(printer_job *pj)
{
Printer support: cfg.printer is assumed to be a Unix command through which to pipe printed data. Of course by default printing is disabled; typically cfg.printer would be set to `lpr', perhaps with some arguments. [originally from svn r2073]
2002-10-15 17:38:04 +00:00
if (!pj)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return;
Printer support: cfg.printer is assumed to be a Unix command through which to pipe printed data. Of course by default printing is disabled; typically cfg.printer would be set to `lpr', perhaps with some arguments. [originally from svn r2073]
2002-10-15 17:38:04 +00:00
pclose(pj->fp);
sfree(pj);
First phase of porting. pterm now compiles and runs under Linux+gtk. The current pty.c backend is temporarily a loopback device for terminal emulator testing, the display handling is only just enough to show that terminal.c is functioning, the keyboard handling is laughable, and most features are absent. Next step: bring output and input up to a plausibly working state, and put a real pty on the back to create a vaguely usable prototype. Oh, and a scrollbar would be nice too. In _theory_ the Windows builds should still work fine after this... [originally from svn r2010]
2002-10-09 18:09:42 +00:00
}
Unix can't sensibly enumerate printers (since they're defined as being lpr commands), so the Unix config box now replaces the printer combo box with an ordinary edit box. [originally from svn r3063]
2003-04-05 16:12:52 +00:00
/*
* There's no sensible way to enumerate printers under Unix, since
* practically any valid Unix command is a valid printer :-) So
Update source file names in comments and docs. Correcting a source file name in the docs just now reminded me that I've seen a lot of outdated source file names elsewhere in the code, due to all the reorganisation since we moved to cmake. Here's a giant pass of trying to make them all accurate again.
2022-01-22 15:38:53 +00:00
* these are useless stub functions, and config-unix.c will disable
* the drop-down list in the printer configurer.
Unix can't sensibly enumerate printers (since they're defined as being lpr commands), so the Unix config box now replaces the printer combo box with an ordinary edit box. [originally from svn r3063]
2003-04-05 16:12:52 +00:00
*/
printer_enum *printer_start_enum(int *nprinters_ptr) {
*nprinters_ptr = 0;
return NULL;
}
char *printer_get_name(printer_enum *pe, int i) { return NULL;
}
void printer_finish_enum(printer_enum *pe) { }
Reference in New Issue Copy Permalink