Recently, I acquired a Brother MFC printer (Brother MFC-L8610CDW), and have installed the appropriate Brother "driver" packages to use it under CUPS.[...]
One of the packages (the brmfcfaxdrv-2.0.2 "Fax" driver package) includes
a commandline user script ("brpcfax")to "print to fax", that seems to have been written by someone with only a rudimentary concept of what users would use it for. Written not in POSIX shell, but in bash, it queues documents to
a fixed-name print queue ("BRFAX") to be faxed by the printer attached to this queue.
The script, while serviceable, seemed to me to be only just barely adequate to it's task, and I have endeavoured to rewrite it so as to provide a few more features and a fair bit more flexibility.
I have tested this rewrite on my own systems, to my own satisfaction. However,
I'm not so vain as to think that what I've coded is universal. So, I'd like to ask if anyone is interested in testing this script for me.
If there's interest, please respond, and I will send (or post) the
man page, the script, and the GPL v2 licence that goes with it.
W dniu 20.04.2026 o 05:04, Lew Pitcher pisze:
Recently, I acquired a Brother MFC printer (Brother MFC-L8610CDW), and have >> installed the appropriate Brother "driver" packages to use it under CUPS.[...]
One of the packages (the brmfcfaxdrv-2.0.2 "Fax" driver package) includes
a commandline user script ("brpcfax")to "print to fax", that seems to have >> been written by someone with only a rudimentary concept of what users would >> use it for. Written not in POSIX shell, but in bash, it queues documents to >> a fixed-name print queue ("BRFAX") to be faxed by the printer attached to
this queue.
The script, while serviceable, seemed to me to be only just barely adequate >> to it's task, and I have endeavoured to rewrite it so as to provide a few
more features and a fair bit more flexibility.
I have tested this rewrite on my own systems, to my own satisfaction. However,
I'm not so vain as to think that what I've coded is universal. So, I'd like >> to ask if anyone is interested in testing this script for me.
If there's interest, please respond, and I will send (or post) the
man page, the script, and the GPL v2 licence that goes with it.
I think it will be good idea drop a line in to Brother company if they
are interested with such "upgrade".
Personally I have only Brother MFC-L2752DW, not business machine like
yours. I think few person can afford Brother MFC-L8610CDW and use it effectively in home.
On Mon, 20 Apr 2026 13:09:06 +0200, 🇵🇱Jacek Marcin Jaworski🇵🇱 wrote:[snip]
W dniu 20.04.2026 o 05:04, Lew Pitcher pisze:
Recently, I acquired a Brother MFC printer (Brother MFC-L8610CDW), and have >>> installed the appropriate Brother "driver" packages to use it under CUPS. >>>[...]
One of the packages (the brmfcfaxdrv-2.0.2 "Fax" driver package) includes >>> a commandline user script ("brpcfax")to "print to fax", that seems to have >>> been written by someone with only a rudimentary concept of what users would >>> use it for. Written not in POSIX shell, but in bash, it queues documents to >>> a fixed-name print queue ("BRFAX") to be faxed by the printer attached to >>> this queue.
The script, while serviceable, seemed to me to be only just barely adequate >>> to it's task, and I have endeavoured to rewrite it so as to provide a few >>> more features and a fair bit more flexibility.
I have tested this rewrite on my own systems, to my own satisfaction. However,
I'm not so vain as to think that what I've coded is universal. So, I'd like >>> to ask if anyone is interested in testing this script for me.
If there's interest, please respond, and I will send (or post) the
man page, the script, and the GPL v2 licence that goes with it.
I think it will be good idea drop a line in to Brother company if they
are interested with such "upgrade".
A good suggestion, Jacek, and one that I will follow up on shortly.
Recently, I acquired a Brother MFC printer (Brother MFC-L8610CDW), and have installed the appropriate Brother "driver" packages to use it under CUPS.[snip]
I have tested this rewrite on my own systems, to my own satisfaction. However,[snip]
I'm not so vain as to think that what I've coded is universal. So, I'd like to ask if anyone is interested in testing this script for me.
On Mon, 20 Apr 2026 03:04:23 +0000, Lew Pitcher wrote:
Recently, I acquired a Brother MFC printer (Brother MFC-L8610CDW), and have >> installed the appropriate Brother "driver" packages to use it under CUPS.[snip]
I have tested this rewrite on my own systems, to my own satisfaction. However,[snip]
I'm not so vain as to think that what I've coded is universal. So, I'd like >> to ask if anyone is interested in testing this script for me.
In recognition of the niche (and declining) status of FAX, and the especially niche status of "print to fax" through a Brother MFC printer, I have licenced my script under the GNU GPL v2, and the associated manpage under the GPL FDL v1.3, and will publish them (the script, and the manpage) here and on my website.
If anyone is interested, they can download the entire source package from
http://justlinux.ca/node/98
Recently, I acquired a Brother MFC printer (Brother MFC-L8610CDW), and have installed the appropriate Brother "driver" packages to use it under CUPS.
One of the packages (the brmfcfaxdrv-2.0.2 "Fax" driver package) includes
a commandline user script ("brpcfax")to "print to fax", that seems to have been written by someone with only a rudimentary concept of what users would use it for. Written not in POSIX shell, but in bash, it queues documents to
a fixed-name print queue ("BRFAX") to be faxed by the printer attached to this queue.
The script, while serviceable, seemed to me to be only just barely adequate to it's task, and I have endeavoured to rewrite it so as to provide a few more features and a fair bit more flexibility.
I have tested this rewrite on my own systems, to my own satisfaction. However,
I'm not so vain as to think that what I've coded is universal. So, I'd like to ask if anyone is interested in testing this script for me.
It replaces /only/ the /usr/bin/brpcfax script (symlinked to /opt/brother/fax/brmfcfax/command/brpcfax), and, in addition to being a
drop in replacement for brpcfax, is
a) written entirely as a POSIX shell script
b) written to allow user selection of the fax printer queue
(where the sysadmin has configured CUPS or LPR(NG) to use a different
queue name for the Brother FAX driver),
c) handles multiple documents (recognizing restrictions of the Brother
Fax driver),
d) properly handles commandline arguments (including file paths) that
include embedded spaces, and
e) returns the exit code of the underlying lpr command, rather than
a fixed 0 returncode
If there's interest, please respond, and I will send (or post) the
man page, the script, and the GPL v2 licence that goes with it.
Thanks in advance--
On 2026-04-20 05:04, Lew Pitcher wrote:
Recently, I acquired a Brother MFC printer (Brother MFC-L8610CDW), and have >> installed the appropriate Brother "driver" packages to use it under CUPS.
One of the packages (the brmfcfaxdrv-2.0.2 "Fax" driver package) includes
a commandline user script ("brpcfax")to "print to fax", that seems to have >> been written by someone with only a rudimentary concept of what users would >> use it for. Written not in POSIX shell, but in bash, it queues documents to >> a fixed-name print queue ("BRFAX") to be faxed by the printer attached to
this queue.
The script, while serviceable, seemed to me to be only just barely adequate >> to it's task, and I have endeavoured to rewrite it so as to provide a few
more features and a fair bit more flexibility.
I have tested this rewrite on my own systems, to my own satisfaction. However,
I'm not so vain as to think that what I've coded is universal. So, I'd like >> to ask if anyone is interested in testing this script for me.
I don't have a brother printer, sorry.
But I wonder what is the issue if the script is written for bash. So
what? I assume that the SHEBANG specifies bash, not posix. I have
scripts in my system that specify a different shell. That's not a
problem, each script uses the shell it was designed for, and I have all
of them installed, space is not a problem anymore.
It replaces /only/ the /usr/bin/brpcfax script (symlinked to
/opt/brother/fax/brmfcfax/command/brpcfax), and, in addition to being a
drop in replacement for brpcfax, is
a) written entirely as a POSIX shell script
b) written to allow user selection of the fax printer queue
(where the sysadmin has configured CUPS or LPR(NG) to use a different
queue name for the Brother FAX driver),
c) handles multiple documents (recognizing restrictions of the Brother
Fax driver),
d) properly handles commandline arguments (including file paths) that
include embedded spaces, and
e) returns the exit code of the underlying lpr command, rather than
a fixed 0 returncode
If there's interest, please respond, and I will send (or post) the
man page, the script, and the GPL v2 licence that goes with it.
I hope they answer and accept your contribution :-)
On Wed, 22 Apr 2026 21:24:56 +0200, Carlos E.R. wrote:
On 2026-04-20 05:04, Lew Pitcher wrote:
Recently, I acquired a Brother MFC printer (Brother MFC-L8610CDW), and have >>> installed the appropriate Brother "driver" packages to use it under CUPS. >>>
One of the packages (the brmfcfaxdrv-2.0.2 "Fax" driver package) includes >>> a commandline user script ("brpcfax")to "print to fax", that seems to have >>> been written by someone with only a rudimentary concept of what users would >>> use it for. Written not in POSIX shell, but in bash, it queues documents to >>> a fixed-name print queue ("BRFAX") to be faxed by the printer attached to >>> this queue.
The script, while serviceable, seemed to me to be only just barely adequate >>> to it's task, and I have endeavoured to rewrite it so as to provide a few >>> more features and a fair bit more flexibility.
I have tested this rewrite on my own systems, to my own satisfaction. However,
I'm not so vain as to think that what I've coded is universal. So, I'd like >>> to ask if anyone is interested in testing this script for me.
I don't have a brother printer, sorry.
But I wonder what is the issue if the script is written for bash. So
what? I assume that the SHEBANG specifies bash, not posix. I have
scripts in my system that specify a different shell. That's not a
problem, each script uses the shell it was designed for, and I have all
of them installed, space is not a problem anymore.
Bash supports a superset of POSIX shell. Ash supports a different superset
of POSIX shell. Korn Shell supports a superset of POSIX shell that's different
from both the Bash and Ash supersets.
What's common to all these is the POSIX shell subset, which works the same way in all three shells.
Brother released it's script in Bash, with bash-isms all around. That
makes using this script on a system /that lacks bash/ difficult, as
someone has to go through the script and change all those bash-isms to something else.
The systems I use have /bin/sh linked to /bin/ash. Yours might have
/bin/sh linked to /bin/bash. In any case, I prefer that the utility
be written in the /common/ subset (as set by POSIX) so that, when distributed, it doesn't require additional site-specific modifications
just to work.
It replaces /only/ the /usr/bin/brpcfax script (symlinked to
/opt/brother/fax/brmfcfax/command/brpcfax), and, in addition to being a
drop in replacement for brpcfax, is
a) written entirely as a POSIX shell script
b) written to allow user selection of the fax printer queue
(where the sysadmin has configured CUPS or LPR(NG) to use a different >>> queue name for the Brother FAX driver),
c) handles multiple documents (recognizing restrictions of the Brother
Fax driver),
d) properly handles commandline arguments (including file paths) that
include embedded spaces, and
e) returns the exit code of the underlying lpr command, rather than
a fixed 0 returncode
If there's interest, please respond, and I will send (or post) the
man page, the script, and the GPL v2 licence that goes with it.
I hope they answer and accept your contribution :-)
Brother answered all right:
"Thanks for reaching Brother Canada and for that piece of information.
Do feel free to share this with the community.
Please contact us if we can be of any further help or if you have any other questions."
:-)
Linux machines without bash do not exist, unless you hate bash and
remove it.
On Mon, 20 Apr 2026 03:04:23 +0000, Lew Pitcher wrote:Things gets a bit more niche as there are so many options out there and
Recently, I acquired a Brother MFC printer (Brother MFC-L8610CDW), and have >> installed the appropriate Brother "driver" packages to use it under CUPS.[snip]
I have tested this rewrite on my own systems, to my own satisfaction. However,[snip]
I'm not so vain as to think that what I've coded is universal. So, I'd like >> to ask if anyone is interested in testing this script for me.
In recognition of the niche (and declining) status of FAX, and the especially niche status of "print to fax" through a Brother MFC printer
eval lpr -P "${FAXPRINTER}" -o fax-number="${FAXTARGET}" $LPR_ARGS $FAX_DOC
A script that starts with #!/bin/bash will just work anywhere.
On Wed, 22 Apr 2026 21:48:41 +0200, Carlos E.R. wrote:
A script that starts with #!/bin/bash will just work anywhere.
Well, not in any *BSD
The 'universal', 'smart' way is: #!/usr/bin/env bash
On Wed, 22 Apr 2026 21:48:41 +0200, Carlos E.R. wrote:
A script that starts with #!/bin/bash will just work anywhere.
Well, not in any *BSD
The 'universal', 'smart' way is: #!/usr/bin/env bash
On 2026-04-23 20:35, Allodoxaphobia wrote:
On Wed, 22 Apr 2026 21:48:41 +0200, Carlos E.R. wrote:
A script that starts with #!/bin/bash will just work anywhere.
Well, not in any *BSD
Not Linux :-)
The 'universal', 'smart' way is: #!/usr/bin/env bash
I've never seen it.
On Thu, 23 Apr 2026 22:30:27 +0200, Carlos E.R. wrote:
On 2026-04-23 20:35, Allodoxaphobia wrote:
On Wed, 22 Apr 2026 21:48:41 +0200, Carlos E.R. wrote:
A script that starts with #!/bin/bash will just work anywhere.
Well, not in any *BSD
Not Linux :-)
The 'universal', 'smart' way is: #!/usr/bin/env bash
I've never seen it.
If I understand the use of /usr/bin/env correctly,
in /this/ case, it will locate bash(1) on the user's
PATH. This implies that bash(1) /is not/ located
in a fixed location (such as /bin, as per your hashbang),
and that env(1) /is/ located in a fixed location
(/usr/bin/env).
From what I can find out, the default shell in
BSD is the Almquist shell (ash(1)), and bash
is an extra that has to be explicitly installed
(looks like it goes in /usr/local/bin).
What is not right is declare in a script that it uses the common shell,
and then have bashisms inside.
Well, not in any *BSD
The 'universal', 'smart' way is: #!/usr/bin/env bash
If I understand the use of /usr/bin/env correctly, in /this/ case,
it will locate bash(1) on the user's PATH. This implies that bash(1)
/is not/ located in a fixed location (such as /bin, as per your
hashbang), and that env(1) /is/ located in a fixed location
(/usr/bin/env).
Allodoxaphobia wrote:
Well, not in any *BSD
The 'universal', 'smart' way is: #!/usr/bin/env bash
What if /usr is not yet mounted?
On 23 Apr 2026 18:35:32 GMT, Allodoxaphobia wrote:
Well, not in any *BSD
The 'universal', 'smart' way is: #!/usr/bin/env bash
What if /usr is not yet mounted?
On 2026-04-24 06:38, Lawrence D’Oliveiro wrote:
On 23 Apr 2026 18:35:32 GMT, Allodoxaphobia wrote:
Well, not in any *BSD
The 'universal', 'smart' way is: #!/usr/bin/env bash
What if /usr is not yet mounted?
Well, that is why #!/bin/bash is used instead.
On 24/04/2026 09:57, Carlos E.R. wrote:
On 2026-04-24 06:38, Lawrence D’Oliveiro wrote:
On 23 Apr 2026 18:35:32 GMT, Allodoxaphobia wrote:
Well, not in any *BSD
The 'universal', 'smart' way is: #!/usr/bin/env bash
What if /usr is not yet mounted?
Well, that is why #!/bin/bash is used instead.
the use of a separate partition for /usr goes back to when /home was not
the default place for user data.
I cant see any advantage in partitioning it in a modern context with
large - and fast - SSDs.
In short its all theoretical cockwombling 'what ifs' rather than a real
life issue...
I cant see any advantage in partitioning it in a modern context with
large - and fast - SSDs.
On 2026-04-24 11:31, The Natural Philosopher wrote:
On 24/04/2026 09:57, Carlos E.R. wrote:
On 2026-04-24 06:38, Lawrence D’Oliveiro wrote:
On 23 Apr 2026 18:35:32 GMT, Allodoxaphobia wrote:
Well, not in any *BSD
The 'universal', 'smart' way is: #!/usr/bin/env bash
What if /usr is not yet mounted?
Well, that is why #!/bin/bash is used instead.
the use of a separate partition for /usr goes back to when /home was
not the default place for user data.
I cant see any advantage in partitioning it in a modern context with
large - and fast - SSDs.
In short its all theoretical cockwombling 'what ifs' rather than a
real life issue...
I do use a number of partitions. I have 4 rotating rust disks on this system. I'm not using now a /usr partition, I removed that one because
it was a pain. And I used it before because I had to enlarge the system,
and root was relatively small.
On 2026-04-24 11:31, The Natural Philosopher wrote:
I cant see any advantage in partitioning it in a modern context with
large - and fast - SSDs.
For example, that if you want to change the partition parameters in a
non full disk partition, you can move the contents to other partitions,
then reformat the target, and restore the contents.
On 24/04/2026 10:45, Carlos E.R. wrote:
On 2026-04-24 11:31, The Natural Philosopher wrote:That's what USB drives are for...
I cant see any advantage in partitioning it in a modern context with
large - and fast - SSDs.
For example, that if you want to change the partition parameters in a
non full disk partition, you can move the contents to other
partitions, then reformat the target, and restore the contents.
On 24/04/2026 10:43, Carlos E.R. wrote:
On 2026-04-24 11:31, The Natural Philosopher wrote:
On 24/04/2026 09:57, Carlos E.R. wrote:
On 2026-04-24 06:38, Lawrence D’Oliveiro wrote:
On 23 Apr 2026 18:35:32 GMT, Allodoxaphobia wrote:
Well, not in any *BSD
The 'universal', 'smart' way is: #!/usr/bin/env bash
What if /usr is not yet mounted?
Well, that is why #!/bin/bash is used instead.
the use of a separate partition for /usr goes back to when /home was
not the default place for user data.
I cant see any advantage in partitioning it in a modern context with
large - and fast - SSDs.
In short its all theoretical cockwombling 'what ifs' rather than a
real life issue...
I do use a number of partitions. I have 4 rotating rust disks on this
system. I'm not using now a /usr partition, I removed that one because
it was a pain. And I used it before because I had to enlarge the
system, and root was relatively small.
Well so did I some time in the early 1990s
Bur seriously, I wouldn't be using spinning rust from that era today.
Too damned dangerous in terms of reliability...
On 2026-04-24 12:11, The Natural Philosopher wrote:
On 24/04/2026 10:45, Carlos E.R. wrote:
On 2026-04-24 11:31, The Natural Philosopher wrote:That's what USB drives are for...
I cant see any advantage in partitioning it in a modern context with
large - and fast - SSDs.
For example, that if you want to change the partition parameters in a
non full disk partition, you can move the contents to other
partitions, then reformat the target, and restore the contents.
Mine are not empty.
On 2026-04-24 11:31, The Natural Philosopher wrote:
I cant see any advantage in partitioning it in a modern context with
large - and fast - SSDs.
For example, that if you want to change the partition parameters in a
non full disk partition, you can move the contents to other partitions,
then reformat the target, and restore the contents.
On Thu, 23 Apr 2026 18:35:32 +0000, Allodoxaphobia wrote:
On Wed, 22 Apr 2026 21:48:41 +0200, Carlos E.R. wrote:
A script that starts with #!/bin/bash will just work anywhere.
Well, not in any *BSD
The 'universal', 'smart' way is: #!/usr/bin/env bash
I'm not so sure about that.
From what I can see, the BSD env(1) command does the same
thing as the Linux/GNU env(1) command: it gives you a
way to alter the environment variables passed to a command
[/SNIP/]
Your "'universal', 'smart'" way doesn't specify any
modifications to the environment. It appears to be effectivly
useless.
(unless I'm misunderstanding the utility of the env(1) utility).
On 2026-04-23 20:35, Allodoxaphobia wrote:
On Wed, 22 Apr 2026 21:48:41 +0200, Carlos E.R. wrote:
A script that starts with #!/bin/bash will just work anywhere.
Well, not in any *BSD
Not Linux :-)
The 'universal', 'smart' way is: #!/usr/bin/env bash
I've never seen it.
Lawrence D’Oliveiro <[email protected]d> writes:
Allodoxaphobia wrote:
Well, not in any *BSD
The 'universal', 'smart' way is: #!/usr/bin/env bash
What if /usr is not yet mounted?
How often does your computer send faxes before /usr is mounted? (Or at
all? Are you posting from the 1980s?)
Anyway, the answer is you edit the #! line to point to /bin/bash or
whatever, and move on with your life.
Le 23-04-2026, Carlos E.R. <[email protected]d> a écrit :
On 2026-04-23 20:35, Allodoxaphobia wrote:
On Wed, 22 Apr 2026 21:48:41 +0200, Carlos E.R. wrote:
A script that starts with #!/bin/bash will just work anywhere.
Well, not in any *BSD
Not Linux :-)
The 'universal', 'smart' way is: #!/usr/bin/env bash
I've never seen it.
Lucky guy. I discovered it when I started to work on some python scripts
with others.
The assumption is that "env" will always always always live in /usr/binA script that starts with #!/bin/bash will just work anywhere.
Well, not in any *BSD
The 'universal', 'smart' way is: #!/usr/bin/env bash
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,114 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 492511:53:37 |
| Calls: | 14,267 |
| Calls today: | 3 |
| Files: | 186,320 |
| D/L today: |
26,173 files (8,479M bytes) |
| Messages: | 2,518,387 |