On Mon, Jun 19, 2006 at 11:54:12AM +0200, oopla wrote:
> > faxinfo-format-4.patch
>
> > old format new format
> > ------------------- -----------------
> > -s '%.0s' -s ''
> > -e '%1$s' -e '%s'
> >
> > Can anyone think of any flexibility *lost* by splitting them up? The
> > simplicity gained seems worth it.
>
> Let me re-check & re-think a bit on that.
1. docs need to point out that opts order is important:
$ ./faxinfo -n -C , /home/oopla/fax07138.tif
"/home/oopla/fax07138.tif","+49 1234 5678","1","Normal","North American
Letter","2002:07:09 15:29:39","1:06","9600 bit/s","1-D MH","No"
$ ./faxinfo -C , -n /home/oopla/fax07138.tif
/home/oopla/fax07138.tif:
,"+49 1234 5678","1","Normal","North American Letter","2002:07:09
15:29:39","1:06","9600 bit/s","1-D MH","No"
the latter looks weird, kinda broken CSV. Also -r -n is different than -n -r.
While that's not foolproof, I like the added flexibility, though at present
one would need to really look into the code or go screaming away ;)
Finally - but that's rather a wishlist for hfaxd, perhaps worth it's own
bug# - I'd rather have hylafax embed into the .tif the following infos
along with 'Sender',... and perhaps faxinfo() may optionally print them
with an opt -l(ocal infos):
- [EMAIL PROTECTED] fax was received on
- either FAXNumber or LocalIdentifier
- either basename(filename) or just the serial#
eg.:
$ ./faxinfo -l /home/oopla/fax07138.tif
Sender: +49 1234 5678
Pages: 1
Quality: Normal
Page: North American Letter
Received: 2002:07:09 15:29:39
TimeToRecv: 1:06
SignalRate: 9600 bit/s
DataFormat: 1-D MH
ErrCorrect: No
Faxname: fax07138.tif
FAXNumber: +39.0000.111111
[EMAIL PROTECTED]: [EMAIL PROTECTED]
reason is that those infos are (part of) the local side story of the fax
that would be lost if file is renamed and archived without
embedding/storing such infos into eg. archive pathname or somesuch.
2. surely -SseE empowers the user, so user take responsibility to not shoot
on his own foot, still it sounds bad to me to allow for something like:
$ ./faxinfo -S '%s%s' -E '\n' /home/oopla/fax07138.tif
Segmentation fault
fully sanitizing a printf() fmt string might not be trivial, though, so
I'd still buy the flexibility/power and let the foolproofness in the
todos :) - pls see at end my current tentative/sub-optimal
escapedString() which should catch just the simple %n case.
3. the new format sounds ok to me - at least I still can do what I meant, and
more, e.g. here's (core part of) a quick .cgi :
$ ./faxinfo -S'<tr><h><a href="%s">%1$s</a></th>' -s'<td>' -e'</td>'
-E'</tr>\n' /home/oopla/fax07138.tif
<tr><th><a
href="/home/oopla/fax07138.tif">/home/oopla/fax07138.tif</a></th><td>+49 1234
5678</td><td>1</td><td>Normal</td><td>North American Letter</td><td>2002:07:09
15:29:39</td><td>1:06</td><td>9600 bit/s</td><td>1-D MH</td><td>No</td></tr>
That's with current implementation.
Now, if we had e.g. -b meaning 'use basename(filename)', sample use above
would allow to have
$ ./faxinfo -b ... :
<tr><th><a href="/some/other/path/fax07138.tif">fax07138.tif</a>...
without 1st do a cd into each faxdir.
-- paolo
...
escapedString (const char*src)
{
char* res;
int len;
len = strlen(src);
res = (char*)calloc(len+1, sizeof(char));
if (res)
{
char* dst = res;
for (int i = 0; i < len; i++)
{
if (i < len-1)
{
switch (src[i])
{
case '\':
switch (src[++i])
{
case 'n': *dst++ = '\n'; break;
case 'r': *dst++ = '\r'; break;
case 't': *dst++ = '\t'; break;
default:
*dst++ = src[i];
}
break;
case '%':
*dst++ = src[i];
switch (src[++i])
{
// don't ever want %n, let's squash it to %%
case 'n': *dst++ = '%'; break;
default:
*dst++ = src[i];
}
break;
default:
*dst++ = src[i];
}
} else
{
*dst++ = src[i];
}
}
} else
exit (ENOMEM);
return res;
}
...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
